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La presente invention concerne d'une facon generate un systeme et un precede de 
conversion dynamique et parametrable d'un ou plusieurs flux de donnees balisees. 

Arriere-plan de rinvention 

1 . L'lntemet et les t61ep hones portables 

En matiere de communication et d'echanges d' informations, les annees 1990 ont 
temoigne d'innovations technologiques dont les repercussions ont aujourd'hui une 
etendue mondiale. Deux grandes causes paraissent etre a la base de ce phenomene : 
la montee en puissance de l'lntemet d'une part, et la multiplication des appareils 
portables « sans fil » - telephones, assistants electroniques - d'autre part. 

On peut differentier ces deux causes car elles n'ont eu au depart ni les m&nes 
origines, ni les memes cibles commerciales. L'lntemet ressort typiquement du 
domaine de l'informatique : la population concernee connait le maniement d'un 
ordinateur et de ses programmes. Le domaine du « sans fil », quant a lui, appartient 
au le monde de la telephonic II est destine a une clientele grand public. 

Bien que differentes au depart dans leur conception, leurs methodes proprietaires et 
leurs applications, il apparait aujourd'hui que ces deux techniques de communication 
electronique vont se rapprocher jusqu'a se confondre. Les consortiums de 
constructeurs (W3C , WAPforum ), les accords reciproques entre les grands 
industriels de la tdlephonie et de rinformatique sont aujourd'hui les premiers jalons 
de cette unification. 

Un objectif essentiel de la presente invention est de permettre de produire des 
donnees exploitables par les telephones portables accedant au reseau Internet. 



2. Les langages balises 



Le format des donnees circulant sur l'Intemet obeit a des normes precises et 
intemationales qui ont favorise son essor. Cette nonnalisation s'applique a toutes les 
couches participant a l'echange de ces donnees : la couche de transport TCP/IP (pour 
« Transmission Control Protocol/Internet Protocol » en terminologie anglo-saxonne), 
le protocole de requete/reponse HTTP (pour «H^erText Markup Language » en 
terminologie anglo-saxone), et finalement le contenu de la reponse elle-meme, la 
page de la Toile (« Web » en terminologie anglo-saxonne). Le langage utilise pour 
decrire une page de la Toile est de type « balise » : il comporte ainsi des balises, 
c'est-a-dire des suites de caracteres qui se differencient du texte parce qu'elles sont 
encadrees par des caracteres speciaux « < » et « > ». La piece de logiciel qui decode 
le document balise s'appelle un analyseur syntaxique (« Parser » en terminologie 
anglo-saxonne). 

Les balises creent une veritable hierarchie au sein du texte, indiquant, par exemple, 
qu'il s'agit du titre du 2eme sous-chapitre du 3eme chapitre du corps du document. 
C'est par l'analyse de cette hierarchie que le navigateur de la Toile decide 
notamment du rendu typographique de chaque portion de texte : litres, paragraphes, 
tableaux, images. 

Outre la syntaxe de l'ecriture des balises qui permet de les distinguer du texte 
normal, la hierarchie des balises fait aussi l'objet de regies : par exemple, un 
paragraphe ne contient jamais d'autres paragraphes, mais un tableau peut contenir 
d'autres tableaux. Publiee en 1986, la norme SGML (pour « Standard Generalized 
Markup Language » en terminologie anglo-saxonne) est la premiere qui definisse la 
formalisation de ces regies, en particulier en termes de syntaxe d'ecriture et de 
description des contraintes hierarchiques. Cette norme SGML donne du langage 
balise une description toutefois purement formelle, sans preciser quelles balises une 
application devra utiliser. La norme SGML est « generique », au sens qu'elle defmit 
les regies communes aux langages de balisage. Mais elle n'est pas, en elle-meme, un 



langage de balisage contrairement a HTML, qui est le langage standard de balisage 
des pages de la Toile. 



3. M&iiocrite du balisap p- des pages de la Toile 

Le langage HTML impose qu'une page contienne une suite de balises fixes bien 
precises (typiquement une centaine ou davantage), les regies du h^lisage se 
conformant en theorie aux principes edictes par la norme SGML. Mais dans la 
pratique, et ce pour des raisons de precedence historique et de complexite de la 
norme SGML, la majorite des informations existantes sur la Toile entrent en conflit 
avec les regies prescrites. 

C'est notamment l'absence d'outils de validation qui a permis la proliferation de ces 
milliards de pages non conformes a la norme SGML, sachant que les concepteurs de 
ces pages pouvaient librement recourir a des truquages pour arriver a leur objectif 
premier, a savoir la qualite du rendu typographique obtenu lors de la visualisation 
des informations. Par exemple, un litre de chapitre au milieu d'un paragraphe permet 
d'obtenir des caracteres gras dans une police de taille plus importante, alors qu'un 
chapitre au sens de la norme ne peut pas se concevoir comme etant imbriquS dans un 
paragraphe. Au sens du balisage, c'est une erreur grave, mais les logiciels de 
navigation, qui ne sont pas des outils de validation, ne le signalent pas. 

II en resulte qu'aujourd'hui, la majority des donnees existantes sur les sites Internet 
sont vouees a une application unique specifique qui est leur visualisation sur ecran 
d'ordinateur par le biais des logiciels de navigation standard tels que « Netscape 
Navigator » ou « Internet Explorer » (marques deposees au nom de leurs titulaires 
respectifs). 

Mais la reutilisation de ces pages en vue d'autres applications (comme par exemple 
l'affichage sur un ecran de telephone portable) ne serait pas envisageable autrement 
que par une degradation consequente du contenu, sans garantie de resultat fiable. 



Un premier objet de la presente invention est de permettre l'adaptation des donnees 
actuellement existantes sur les sites en vue de leur traitement par une diversite 
d'applications, sans necessiter une refonte prealable de ces donnees. 

4. La norme XML 

Des outils de validation sont apparus a peu pres dans les annees 1993, en revelant au 
passage l'etendue des erreurs du balisage de la plupart des pages de la Toile. A cet 
egard, les organisations qui regissent la Toile se livrent a de nombreuses tentatives de 
normalisation : definition de regies hierarchiques strictes d'une part, mais aussi 
laxistes d'autre part, dites transitionnelles, dans le but declare de recuperer le plus 
grand nombre de documents errones. Malgre ce, il devient impossible d'endiguer le 
flot croissant de documents g6neres en violation de la norme. Les mauvaises 
habitudes sont deja ancrees et les auteurs refusent ces changements qu'ils ne 
comprennent pas. 

Pour prendre en main le probleme, un consortium denomme W3C a ete cree et, des 
1997, a publie la norme XML (pour « extensible Markup Language » en 
terminologie anglo-saxonne) qui derive de la norme SGML en la simplifiant, mais 
qui aussi renforce de facon stricte la syntaxe. La norme XML a remporte un succes 
considerable dans le monde industriel d'abord, et se popularise peu a peu. Parmi les 
nombreux exemples d'applications, les telephones portables accedant a l'lnternet 
utilisent le langage de balisage WML qui respecte scrupuleusement la norme XML ; 
dans le merae esprit, les constructeurs de base de donnees fournissent les moyens 
d'extraction du contenu dans un format XML ; ainsi la specification EDI (Electronic 
Data Interchange en terminologie anglo-saxonne) est en voie de normalisation XML. 



II apparait toutefois pour les praticiens que la norme XML, avec ses regies strictes, 
n'enrichit pas, voire appauvrit la norme SGML, plus permissive sur les omissions de 
balises courantes. 



* 4 



Comrae on le verra plus loin, un autre objectif de la presente invention est la mise au 
point d'un analyseur syntaxique SGML validant a tolerance de fautes. II comporte 
des algorithmes complexes resolvant la plupart des anomalies de balisage et produit 
5 un flux de donnees en conformite stride avec la norme XML. 

5. Converf-;-">h 

Comme vu plus haut, le respect des regies de hierarchie des balises permet la 
10 production de documents accessibles a une multiplicite d'applications diverses. En 
effet, le but du balisage est d'informer du r61e de telle ou telle portion d'information 
(de texte, d'image), sans presumer de l'usage qui doit en etre fait. Chaque application 
specifique traitant ces documents precede d'une maniere qui lui est propre. 

1 5 Derivant de la norme SGML, la norme XML est « gen6rique », en ce sens qu'il n'est 
pas un langage de balisage par lui meme. Une page de la Toile qui respecterait la 
norme XML est ecrite dans le langage XHTML (pour « extended HyperText 
Markup Language » en terminologie anglo-saxonne). A supposer qu'une telle page 
existe, une question qui se pose est de savoir comment traiter les informations qui y 

20 sont contenues afin de les presenter sur un telephone mobile qui presente des 
caracteristiques fondamentalement differentes de celles d'un ordinateur personnel. 

Sur ce sujet, les publications d'un groupe de travail denomme WAP Forum (WAP 
pour « Wireless Application Protocol » en terminologie anglosaxonne) contiennent 

25 des recommandations qui etablissent que, pour produire un document pouvant etre 
visualise sur un telephone cellulaire (en particulier selon la norme WML pour 
« Wireless Markup Language » en terminologie anglo-saxonne), il faut d'abord 
construire un « super document » au format XML. Ce document, traite par une 
transformation de type XSL (pour « extensible Style Language » en terminologie 

30 anglo-saxonne) pourra generer soit du code en HTML , soil du code en WML, selon 
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le script (a savoir une feuille de style au format XSL) utilise par la transformation. 
Ceci est illustre schematiquement sur la figure 1 des dessins. 

II d6coule de ces evolutions normatives qu'il n'est pas question de pouvoir reutiliser 
les documents HTML existants, mais que de nouveaux documents doivent etre crees 
de toutes pieces de telle maniere qu'une transformation appropriee par un script XSL 
permette de reconstituer le document dans sa version HTML, si necessaire. 

Mais a ce sujet, on peut s'attendre a ce que la plupart des sites de la Toile refuseront 
1'approche drastique proposes par le WAP Forum. En particulier, les sites 
« personnels » ne voudront pas changer par manque de temps pour la re-ecnture. 
Quant aux sites « professionals moyens » (joumaux, bourse, transports, etc.), leurs 
producteurs ont deja beaucoup investi dans 1'ecriture HTML de leurs pages, dans la 
creation des automatismes dans les langages cgi-bin et JavaScript (sachant que 
1'environnement JavaScript que procure XML n'est pas compatible). Enfin et 
surtout, les producteurs de ces sites ont lourdement investi dans la mise au pomt du 
mecanisme d'ensemble, notamment pour faire face a Incompatibility des 
navigateurs Netscape / Internet Explorer. 

En outre, la norme XML releve d'une « culture informatique » differente : l'histoire 
a revele les difficultes du langage SGML qui ne s'est jamais vraiment impose 
principalement parce que le concept de hierarchie du balisage n'est ni simple, m 
populaire. Certes le langage XML a simplifie la syntaxe du langage SGML, mats, 
comme avec SGML, un document ecrit dans le langage XML se doit de respecter la 
, hierarchie des balises. Ainsi, en depit de la popularite croissante de XML, qui a ete 
benefique pour le diffusion du concept de balisage, on ne doit pas s'attendre a ce que 
le langage XML apporte beaucoup plus que le langage SGML, son ancetre. 

II ne semble done pas realiste de s'attendre a une generalisation massive de 
0 Papproche XML/XSL, si ce n'est peut-etre a tres long terme, mais l'on ignore ce que 
sera devenu alors cette technologic 
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La presente invention a en particulier pour objet d'offirir une alternative a cette 
Evolution normative, qui permette, contrairement aux recommandations qui imposent 
une re-ecriture des pages de facon compatible XML, de pouvoir effectuer des 
transformations sur la plus grande partie des pages HTML, existantes, y compris la 
grande proportion de celles-ci qui component des fautes d'ecriture. 

Plus precisement, grace a un mecanisme a conversions multiples extremement 
souple, la presente invention vise a ce que les donnees a convertir ne necessitent pas 
d'etre normalises en XML, ni meme de respecter strictement la hierarchie des 
balises. Ceci est illustre schematiquement sur la figure 2 des dessins. 

Un autre objet encore de la presente invention est d'offrir, pour realiser de telles 
conversions, une syntaxe d'ecriture d' instructions particulierement simple a mettre 
en aeuvre. 

Ainsi la presente invention propose ysteme de conversion de documents, destine a 
transformer un premier document existant dans un premier format balise a structure 
arborescente de noeuds en un second document dans un second format balise a 
structure arborescente de noeuds, caracterise en ce qu'il comprend : 

un ensemble de procedures-gabarits (Template), chaque procedure-gabarit 
dudit ensemble contenant une premiere information de selection d'une etendue de 
parcours de la structure arborescente du premier document, une seconde information 
de selection d'un type de balise du premier document auquel la procedure gabarit 
peut s'appliquer, et un ensemble d'une ou plusieurs actions, au moins certaines 
procedures gabarits contenant des actions de collecte d'informations delimitees par 
les balises dont le type correspond a celui defini par la seconde information de 
selection de ces procedures gabarits, 
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un programme contenant des instructions standard (applyTemplates) pour 
selectivement appeler lesdites procedures gabarits, 

des moyens de traitement repondant audit programme et aptes, lors de 
l'appel d'une procedure-gabarit, a parcourir les nceuds de la structure arborescente 
5 inclus dans son etendue telle que definie par la premiere information de selection de 
ladite procedure-gabarit, et pour chaque noeud parcouru, a determiner si le type de 
balise correspondant audit noeud correspond a la seconde information de selection, et, 
dans l'affirmative, a exercer la ou les actions correspondantes, et 

des moyens aptes, a partir des actions de collecte contenues dans les 
1 0 procedures-gabarits executees, pour construire le second document. 

Certains aspects preferes, mais non limitatifs, du systeme selon rinvention sont les 
suivants : 

15 - les actions d'au moins certaines procedures-gabarits contiennent des instructions 
d'appel d'autres procedures gabarits. 

- la premiere information de selection d'etendue d'une procedure-gabarit est basee 
sur un noeud de depart constitue par le noeud a partir duquel ladite procedure-gabarit 

2 0 est appelee. 

- au moins certaines procedures-gabarits contiennent des actions de creation de 
variables temporaires cloltrees, tandis que chacune de ces variables cloitrees est 
heritee par toute procedure-gabarit appelee par de telles procedures-gabarits. 
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- les procedures-gabarits comprennent une procedure-gabarit de base possedant la 
seconde information de selection correspondant a un noeud racine de la structure 
arborescente du premier document, tandis que les actions de ladite procedure-gabarit 
de base comprennent un appel de procedures-gabarits. 
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- les actions de ladite procedure-gabarit de base comprennent un appel de 
procedures-gabarits dont la seconde information de selection correspond a un type de 
balise « corps ». 

- la structure arborescente de noeuds du premier document comprend des noeuds de 
type « cadre », et en ce que les actions de ladite procedure-gabarit de base 
comprennent un appel de procedures-gabarits dont la seconde information de 
selection correspond a un type de balise « ensemble de cadres ». 

- au moins certaines procedures-gabarits comprennent au moins une action de 
redirection vers un premier document different, sur lequel lesdits moyens de 
traitement sont appliques sur la base du mSme programme. 

- au moins certaines procedures gabarits comprennent au moins une action 
conditionnelle basee sur le contenu d'une adresse d'acces au premier document. 

- au moins certaines procedures-gabarits comprennent au moins une action 
constituent une methode d'un objet et/ou au moins une action constituent une 
fonction locale programmee. 

- certaines procedures-gabarits comprennent une fonction locale d'ancrage apte a 
convertir une requete adaptee a la structure du second document en une adresse d'un 
premier document contenant 1' information recherchee. 

- les moyens de construction du second document comprennent des actions d'ecriture 
contenues dans certaines procedures-gabarits dont la seconde information de 
selection definit une balise a contenu, lesdites actions d'ecriture etant aptes a 
assembler de facon predeterminee au moins une partie des contenus desdites balises. 

- les premiers documents comprennent des pages structures dans un langage balise 
standard adapte a une consultation sur poste informatique client via l'Internet, tandis 
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que les seconds documents comprennent des pages structures dans un second 
langage balise standard adapte a une consultation sur appareil miniature portable. 

- le systeme constitue un gradin d'une architecture multi-gradins. 

L'invention propose en outre une architecture informatique multi-gradins, 
caracterisee en ce c-u'elle comprend en succession, relies par reseau informatique, un 
premier gradin de consultation de donnees sur poste client, un second gradin 
^application sur serveur, un troisieme gradin d'agregation de donnees comprenant 
un systeme de conversion tel que defini ci-dessus et un quatrieme gradin comprenant 
une pluralite de types de sources de donnees independantes. 

Par exemple, dans une application de consultation notamment via l'Internet de 
donnees agglomerees provenant de sources differentes, cette architecture est en outre 
caracterisee en ce que la pluralite de types de sources de donnees independantes 
comprennent au moins deux types de sources parmi les serveurs Internet, les serveurs 
d'annuaires a acces rapide et les serveurs de bases de donnees a acces standard par 
requites. 

) L'invention propose enfin une architecture informatique/t61ephonique multigradins, 
caracterisde en ce qu'elle comprend en succession, relies par reseau informatique et 
par reseau telephonique sans fil, un premier gradin de consultation de donnees sur un 
appareil portable tel qu'un telephone portable, un second gradin de transport de 
donnees sans fil, un troisieme gradin comprenant un systeme de conversion de 

5 documents tel que defini plus haut et un quatrieme gradin comprenant au moins un 
type de source de donnees. 

Par exemple, dans une application de consultation de donnees de serveurs Internet 
standard a partir de telephones portables, cette architecture est en outre caracterisee 
0 en ce que ledit type de source de donnees consiste en des pages structures dans un 
langage balise standard adapte a une consultation sur poste informatique client, 



lesdites pages constituant des premiers documents, et en ce que le systeme de 
conversion compris dans le troisieme gradin est apte a construire des seconds 
documents dans un second langage balise standard adapte a une consultation sur 
appareil miniature portable. 

Breve description des dessins 

D'autres aspects, buts et avantages de la presente invention apparaitront mieux a la 
lecture de la description detaillee suivante d'une forme de realisation preferee de 
celle-ci, donnee a titre d'exemple non limitatif et faite en reference aux dessins 
annexes, sur lesquels : 

la figure 1, deja decrite, est une representation schematique de 1'approche classique 
pour adapter un m6me contenu a differents environnements physiques et logiques de 
navigation sur la Toile, 

la figure 2, egalement deja decrite, est une representation schematique de 1'approche 
retenue selon la presente invention pour atteindre le meme type d'objectif, 

la figure 3 illustre schematiquement un ensemble de blocs fonctionnels mis en ceuvre 
selon la presente invention, 

les figures 4 et 5 illustrent schematiquement deux exemples d' architecture a gradins 
dans lesquelles peut s'integrer le systeme de la presente invention, 

la figure 6 illustre schematiquement une transformation d'arbre en flux realisee selon 
P invention, 



la figure 7 illustre plus en detail une transformation d'arbre selon P invention, 
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les figures 8 a 15, 17 et 18 illustrent des extraits de scripts ecrits dans le langage 
ECMAScript et utilises dans un exemple de mise en oeuvre de la presente invention, 

la figure 16 illustre une structure d'arbre d'une partie d'un document de depart 
5 concernant l'exemple de mise en ceuvre precite, 

la figure 19 illustre la prdsentation visuelle d'un docum^t d'origine et d'un 
document converti selon la presente invention, 

10 les figures 20 a 27 illustrent differentes parties d'un journal de trace susceptible 
d'etre genere par le systeme de la presente invention, et 

la figure 28 illustre une Description Technique de Document definissant le format 
des scripts de conversion utilises par la presente invention. 
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Description detaUlee d'une forme de real isation oreferee de I'invention 



On notera a titre preliminaire que la plupart des concepts, specifications, normes, etc. 
auxquels se refere la presente description font l'objet de descriptions detaillees 
2 0 accessaries sur le site Internet www.w3.org du Consortium W3C precit6. 

On notera egalement que les differents noms de marques cites dans la presente 
description et apparaissant sur les dessins sont des marques deposees aux noms de 
leurs titulaires respectifs. 

25 

1 . L'arbre d'un document 

Comrae on le verra en detail plus loin, la conversion que vise a realiser la presente 
invention necessite non seulement d'examiner le contenu des informations, mais 
30 egalement de prendre en compte leur signification dans un contexte : donnees d'un 
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paragraphs d'un Hen hypertexte, d'une image, d'un son, numero de carte de credit, 
etc. 

Le mecanisme de conversion selon invention s'appuie sur la possibility de 
5 representation en arbre d'un document, propriete fondamentale de tout document 
correctement balise : ainsi la branche « corps du document » d'un document possede 
des sous-branches « chapitre » qui possedent a leur tour des branches « sous- 
chapitre », etc. 

10 La theorie des arbres (navigation et transformations) est une des th6ories 
fondamentales du traitement de donndes. C'est ainsi que la conversion du contenu en 
fonction du contexte utilisee selon la presente invention met en ceuvre une technique 
de transformation d'arbre connue en soi. 

15 La theorie des arbres etant abstraite, son application concrete necessite de decrire : 

- les caract6ristiques de l'arbre (que sont les branches, que sont les feuilles ?) ; 

- la navigation au sein de l'arbre (comment par exemple retrouver un ancetre dans un 
arbre genealogique ?) ; et enfin 

- la transformation de l'arbre (comment par exemple creer un arbre de cousins 
20 germains ?). 

Le consortium W3C precite preconise l'utilisation de la specification DOM 
(« Document Object Model » en terminologie anglo-saxonne) pour decrire l'arbre 
XML en termes de modele de document, et preconise l'utilisation des langages XSL 
25 et XSLT (pour « extensible Style Language Transformations » en terminologie 
anglo-saxonne) pour leur transformation. 

La mise au point de la presente invention a conduit a une etude approfondie de ces 
methodes, en les replacant dans un contexte industriel d'utilisation. 

30 



A cet egard, un objectif annexe de la presente invention a ete d'optimiser les 
standards existants. 

Pr6nec par les techniques de script dynamique de type DHTML (pour « Dynamic 
5 HTML » en terminologie anglo-saxonne), la specification DOM s'impose comme le 
moyen reconnu qui permet la navigation dans les ncuds de P arbre d'un document. 

Ainsi la presente invention utilise la syntaxe DOM pour decrire Farbre du document, 
avec certaines extensions de type agent de corresponds MATCHER, que 1'on 
10 detaillera plus loin, destinecs a obtenir une plus grande efficacite dans les traversees 
de l'arbre. 

On observers ici que la transformation edictee par le langage XSL et par les 
transformations XSLT se fonde sur une approche classique « selection de 
noeuds/choix de gabarits ». Cette approche, deja preconisee par la norme DSSSL 
(pour « Document Style Semantic and Specification Langage » en terminology 
anglo-asxonne), semble etre 1'un des points positifs du langage XSL Mais le langage 
XSL est, dans son application industrielle, relativement complexe, et done met en jeu 
des connaissances specifies et necessite 1'apprentissage d'un nouveau langage de 
programmation. En outre, XSL/XSLT ne permet pas la navigation DOM et ne 
permet pas de b6n6ficier des outils de programmation les plus reconnus. 

En d'autres termes, la presente invention telle qu'on va la decrire en detail constitue 
un choix optimal parmi une multiplicite d'approches conflictuelles, en proposant une 
technique d'assemblage unique harmonisant les interactions entre les outds les plus 
pratiques dans le monde de l'industrie documentaire. 
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2. T ,a conversion de documents 



30 La conversion d'un document balise selon la presente invention est parametree par 
un script, dit « script de conversion », qui est programme dans un langage de 



conversion essentiel pour la mise en oeuvre de la presente invention. Ce langage 
« federateur » centralise la communication avec les divers modules fonctionnels 
independants requis pour la conversion : 

* module DOM d'acces aux noeuds de l'arbre du document en entree, module 
d'analyse et de recherche de texte (incluant un moteur de recherche par expression 
r6guliere) ; 

* module d'ecriture du ' . cument r&sultat (incluant un moteur d'epuration); 

* module d'iteration (traversee de l'arbre par selection de nceuds) ; 

* module de maintenance des variables (au niveau global, ou dans renvironnement 
de service) ; 

* module de creation d'objets Java ; 

* module de trace (debogage). 

La syntaxe du langage de conversion est dans le present exemple ECMAScript , tel 
que strictement specific par la norme du meme nom. ECMAScript - dont JavaScript 
est une extension - est un langage simple, couramment pratiqu<§ par les 
programmeurs de la Toile. Comme on l'a indique plus haut, ceci evite de creer pour 
le programmeur une nouvelle syntaxe, tout en evitant de passer par les scripts balises 
selon le langage XSL. Pour tous complements d'informations sur le langage 
ECMAScript, on pourra notamment se referer aux informations disponibles sur le 
site Internet www.ecma.ch. 

Les d6tails du fonctionnement du langage de conversion sont donnes plus loin. 
3. Description fonctionnelle de Tin vention 

Le systeme et le procdde de la presente invention combinent trois fonctions 
essentielles, dont la premiere est toutefois facultative pour des documents balises 
convenablement construits : 
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a) regroupement et transformation des documents ballses qui derogent aux 
standards 

Comme on l'a dit plus haut, dans les milliards d'octets de pages de donnees 
electroniques existant sur la Toile, la majorite de ces pages sont en violation de 
l'aspect structuration de la norme HTML et, en consequence, ne peuvent etre 
traitees ; cette fonction a pour but de recuperet h plupart des donnees existantes et de 
les normaliser : elle met en oeuvre des algorithmes a tolerance de fautes developpes 
de maniere a restituer un « arbre de document » conforme aux prescriptions de XML. 

b) langage de conversion de cette transformation destine a des applications en 
environnement industriel. 

Ce langage de conversion a ete concu pour offrir une souplesse remarquable dans le 
5 parametrage de la conversion de tout document balise. Les caracteristiques de ce 
langage de conversion en font un langage puissant , tout en restant facile a mettre en 
ceuvre. 

c) outil convertisseur XGate integrant en un seul produit la transformation en mode 
20 flux dynamique 

Cet outil corrige les documents a convertir, interprete le script de conversion et 
produit le resultat dans un mode de « flux continu » : un nombre theoriquement 
illimite de documents peuvent etre convertis en simultane, sous reserve de la bande 
2 5 passante liee notamment a la puissance de calcul et a la memoire disponible. 

La bibliotheque des programmes de conversion est ecrite de preference en langage 
Java. Une application particulierement revelatrice consiste en la traduction 
automatique du contenu de sites quelconques de la Toile. Elle utilise un script 
30 approprie, ecrit dans le langage de conversion, pour traiter le plus grand nombre de 

sites « en aveugle ». 



D'autres scripts ecrits dans le langage de conversion peuvent etre developpes pour la 
traduction sur les telephones portables de sites HTML cibles (par exemples 
aeroports, resultats sportifs, etc.). 

Les bases techniques utilisees pour la mise en oeuvre de la presente invention sont de 
preierence les suivantes : 

* Langage Java (Java 1.2, 100% Pure Java), interpr&eur ECMAScript ; 

* Architecture a gradins pour le contrdle des demandes a cibles multiples, le 
regroupement et l'organisation en document balises des reponses ; 

* Analyseur syntaxique SGML pour une analyse a tolerance de fautes des documents 
balises, pour la mise aux normes XML, et pour la generation de l'arborescence du 
document resultant en tant que mode dynamique de representation du contenu des 
donnees originelles ; 

* Transformation dynamique d'arbre a arbre via un script de type: 
« modele/correspondance/s61ection » (« template/match/select » en tenninologie 
anglo-saxonne »), mais introduisant d'autres concepts uniques (interpreter 
ECMAScript, recherche par expressions regulieres, acces direct aux nceuds par 
navigation DOM, environnement de transformation et de service). 

Les applications de la pr6sente invention sont nombreuses : 

* Commerce electronique ; 

* Conversion de page de la Toile a destination de materiels sans fil ; 

* Suivi de concurrence par analyse intelligente de contenus ; 

* Generation de flux multimedia a partir de sources multiples (musique, images, 
etc.). 

Les avantages qu'elle apporte sont principalement les suivants : 



* Securite et facilite de deploiement par la centralisation de l'acces aux ressources ; 
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* Facilite de mise en oeuvre et d'adaptation des scripts de transformation ; 

* Extensibility et efficacite du fait de la separation des couches d'acces et de logique 
applicative (transformation) ; 

* Stability : P architecture "ouverte" du systteie met a profit les techniques standard 
utilises sur Plnternet : HTTP en tant que protocole de transfert, XML en tant que 
format universel de donn6es structures, ECMAScript en tant que langage de 
transformation. 

4. Description detaillee 

41. Ensemble des modules fonctionnels du convertisseur XGate 

Le schema iilustr6 sur la figure 3 des dessins reprdsente les composants essentiels du 
convertisseur. 

Les donn£es sources sont symbolis6es par le module « Back-ends ». 

Le module « Business Applications » represente la logique de P application cliente, 
aliment6e par les donnfes transformees par le convertisseur XGate. Ce module 
constitue par exemple la partie logique applicative d'une P application de commerce 
6iectronique, telle qu'elle est presentee dans Pexemple donne plus loin. Comme 
indique dans ce tneme exemple, la Business Application communique par les ports 
HTTP, en constituant un gradin sp6cifique au niveau TCP/IP. Mais dans les cas les 
plus simples le module « Business Application » peut ne pas exister. Le client 
communique alors directement avec la sortie du convertisseur XGate, Poutil de 
communication etant le plus souvent un navigateur standard de la Toile. 

Le role du module « Broker » est de decomposer chaque requete en ordres a 
destination d'un module de normalisation « Normalizer » et d'un module de 
transformation « Transformer ». Le module « Broker » a acces a un module 
« Repository » destine a enregistrer les requetes les plus courantes et les profils qui y 
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sont associes. Par exemple, dans le cas d'une transformation d' informations codees 
en HTML vers des informations codees en WML (typiquement pour rendre 
accessibles sur des telephones portables des informations accessibles sur des sites 
Internet), le module « Repository » connait les caracteristiques physiques du modele 
5 de telephone portable qui soumet la requete (dimensions de l'ecran, etc.) II connait 
avantageusement aussi le profil de l'appelant (ses sites preferes, etc.). 

Le module « Normalizer » repond a une requete (fleche « Actions ») en activant le 
nombre de donnees sources necessaires. Le module « Normalizer » restitue ces 

10 donnees au format XML. C'est dans ce module « Normalizer » que se trouve le 
composant d'analyse syntaxique a tolerance de fautes. Mais ce module peut 
egalement contenir d'autres composants : par exemple, si les donnees d'un « Back- 
ends » auquel il accede sont structurees en une base de donnees, le module 
« Normalizer » doit pouvoir engendrer un balisage specifique a ce type de requ&e : 

1 5 c'est le role du composant de filtrage « Filter » de engendrer ce balisage. 

On notera que, pour une requete « Actions » donnee, le nombre de documents XML 
generes depend du nombre de sources de donnees activees. 

20 Le module « Transformer » repond a une requete (fleche de type « Layout ») en 
lisant le flux XML emis par le module « Normalizer » et en lui appliquant le ou les 
scripts de transformation tels que choisis par le module « Broker ». Si besoin est, le 
module « Transformer » a la possibility de retourner une requete complementaire au 
module « Broker » (ce qui n'est pas symbolise sur la figure 3 pour des raisons de 

25 lisibilite). 

4.2. Exemples d' architectures fonctionnelles 
4.2.1. A pplication de commerce electronique 

30 
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La figure 4 illustre 1' integration du convertisseur XGate de la presente invention au 
sein d'une architecture a 4 gradins pour une application de commerce 61ectronique. 

Dans le present exemple, le but de cette application est de fournir aux clients un 
catalogue de produits comportant images, prix, et adresses des foumisseurs. Les 
clients utilisent un navigateur de Toile pour la visualisation des resultats. 

Les differentes informations necessaires proviennent de source heteiogenes, ici une 
base de donnees « SQL Server » pour les prix, un serveur « LDAP Server » pour les 
adresses (Lightweight Directory Access Protocol en terminologie anglo-saxonne - il 
s'agit d'un protocole normalise facilitant la recherche d' informations organisees en 
annuaire ou en repertoire, telle que la recherche de personnes classees selon leur 
nom, leur entreprise, leur pays, etc.), et un serveur « Web Server » pour des pages de 
la Toile decrivant les produits (texte, images, son, etc.). 

Une logique applicative bien concue se doit d'etre affranchie de toute question 
relative a Tobtention des informations qu'elle traite. De meme, la facon dont ces 
informations sont affichees physiquement sur l'ecran du demandeur n'est pas du 
ressort de l'application. Pour ce dernier point, le navigateur de Toile traduira le flux 
HTML emis par la logique applicative en termes d' instructions d'affichage qui 
produiront le resultat correspondant sur l'ecran de I'ordinateur du client. 

Le resultat produit par la logique applicative est done un flux HTML dont 
l'interpretation en images est effectuee sur I'ordinateur du client : e'est la notion de 
"gradin" indiquee plus haut. 

Chaque gradin possede une responsabilite bien defmie, et 1'interface de presentation 
au niveau du poste client constitue le premier gradin de cette architecture. 

Symetriquement, l'obtention et l'assemblage des informations necessaires font 
l'objet d'une entite fonctionnelle (gradin) separee, car on rappelle que ce n'est pas le 
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role de la logique applicative. Le convertisseur XGate assure cette tache en 
produisant un flux de donnees de resultat dans le langage XML. Ce langage a ete 
naturellement choisi dans cet exemple comme le langage f&terateur : sa souplesse 
permet en effet de definir la structure de balisage la plus approprtee aux besoins de 
5 telle ou telle application. 

Le convertisseur XGate permet d'aj outer un niveau de modularity essentiel : la 
collecte et la normalisation des donnees h6t6rogenes. En d'autres termes, la logique 
applicative ne fait que specifier en XML ses besoins, via un script XF de conversion 
10 requ&e/resultat. Cette approche en 4 gradins (le quatri&ne gradin 6tant au niveau du 
fournisseur de donnees) permet un developpement aise, facilement modifiable et 
reutilisable, de cet exemple de commerce electronique. 

4.2.2. Conversion de HTML vers WML 

15 

La figure 5 illustre Faeces a partir d'un telephone portable aux horaires de vol 
d'avions au d6parts et arrivee des principaux aeroports fran9ais. La faisabilit6 de 
cette application a 6t€ experimentee avec succes sur trois modeles de telephones 
portables (Nokia 7110, Motorola TimePort P7389, Siemens S35I - marques 
20 d6pos6es). L'appel d'un numero priv6 a partir d'un tel telephone portable permet 
d'obtenir les horaires des vols, les retards et annulations, affich^s lisiblement, et mis 
a jour minute par minute. Le site test<§ n'a bien sur subi aucune modification 
(d'ailleurs, aucun contact n'a ete pris avec les responsables de ce site). 

25 Comme dans l'exemple precedent, le premier gradin est Pinterface de presentation : 
il s'agit dans ce cas du telephone lui-meme. II communique avec le reseau GSM en 
mode CSD (plus communement appele DATA, par opposition au mode SMS - 
« Short Message Service » en terminologie anglo-saxonne). 

30 Sans entrer dans les details sortant du cadre de la presente invention, le deuxieme 
gradin (adaptation et transport, WSP/WTP, a savoir « Wireless Session Protocol 



specification/Wireless Transaction Protocol specification en terminologie anglo- 
saxonne) pennet au convertisseur XGate de «voir» le telephone comme un 
dispositif IP emettant une requete HTTP et attendant une reponse HTTP en retour. 
Ce gradin garantit une independance vis-a-vis de la technologie GSM utilisee, fait 
particulierement important etant donne Involution rapide des technologies 
concernees. 

Le convertisseur XGate se trouve au troisieme gradin. II dialogue avec le site 
concerne, dechiffrant les informations, soumettant d'autres requetes jusqu'a obtenir 
l'information que le teldphone appelant demande. II traduit alors la reponse en 
generant les balises WML necessaires a Taffichage en clair de cette reponse sur 
l'ecran du telephone. 

Responsable du parametrage de cette transformation, le script de conversion XF est 
peu volumineux ; typiquement, il n'excede pas une page de code. 

4.2.3. Transformat ion en flux 

La figure 6 des dessins synthetise le fonctionnement du convertisseur XGate en 
termes de flux et d'interface ; ainsi il ne s'agit pas sur cette figure de modules 
fonctionnels. 

Une possibilite interessante offerte par la presente invention est d'effectuer le travail 
de conversion en flux continu. Cette caracteristique est responsable de la rapidite de 
la reponse : ainsi, si la transformation le permet, les premieres donn6es en sortie 
peuvent etre produites avant d'avoir lu les donnees en entree dans leur totalis. 

Les arbres des documents d'entrde et de sortie, definis en specification DOM, sont au 
coeur de la conversion. Les fleches representent la transformation noeud a nosud de 
ces arbres, transformation pilotee via le module « Transformer » interpretant le script 

de conversion XF. 
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L'interface « Normalizer » participe a la construction de Parbre en entree. II est 
important de noter ici que la technique en flux continu n' impose pas une construction 
complete de Farbre comme une condition necessaire au d6marrage de la 
transformation : ainsi, ce n'est qu'au moment ou la transformation demande une 
5 branche qui n'est pas encore construite que l'interface « Normalizer » lira 
suffisamment de donn6es en entree pour construire cette branche. 

L'interface « Finalizer » est quant a elle chargte de fournir le flux de sortie, en 
parcourant l'arbre DOM resultant. Cette tSche est permanente : si Tune des branches 

10 est incomplete, alors seuiement l'interface « Finalizer » attendra que la 
transformation de cette branche soit terminee. Notons une autre caract&istique de 
rinterface « Finalizer », a savoir la possibility qu'elle a d'epurer ie flux de sortie. Par 
exemple, les tetephones portables ne reconnaissent pas ies codifications HTML des 
caracteres accentues, car la Description Technique de Document (DTD) du langage 

15 WML n'inclut pas la codification des caracteres accentues. L'interface « Finalizer » 
possMe done avantageusement un composant de conversion des caracteres accentues 
en caracteres correspondants non accentu6s. 

4.2.4. Agreeation et transformation 

20 

La figure 7 des dessins, correspondant k un exemple simplifie, montre quelques unes 
des 6tapes de la transformation realisee par le script de conversion XF pour 
l'application de commerce electronique decrite plus haut. L'interface « Normalizer » 
a cre6 les arbres DOM de trois documents XML resultant de la recherche : 

25 QUERYDOC (recherche du produit dans la base de donnee), DIRDOC (recherche 
d'adresses dans la base LDAP), HTML (document contenant les images). Le script 
de conversion XF construit le document resultant, RESDOC, par une selection des 
nceuds appropries dans chacun des 3 arbres. Cet exemple permet de se rendre compte 
a la fois de la complexity de Foperation, et, en consequence, de la puissance du 

30 langage de conversion dans lequel est ecrit le script XF qui, par sa syntaxe et ses 
fonctionnalites en facilite la programmation. 



Le modele du document RESDOC (schema XML, ou au format DTD pour 
« Document Technical Description » en terminologie anglo-saxonne) est specifie 
dans le deuxieme gradin « Logique Applicative » de la figure 4. Le role du 
convertisseur XGate est de decharger cette application de la recherche et de 
l'assemblage de ce document, operation qui serait extrSmement complexe si une 
« programmatic* classique » avait 6t6 mise en ceuvre. 

Le schema de la figure 7 sous-entend que les trois arbres sont independants, en ce 
sens que le convertisseur XGate les construit en parallele. Mais dans la pratique, la 
construction des trois arbres en entree est interdependante. Par exemple, la recherche 
d'un produit dans la base de donnees renseigne le nom du distributeur (CPNY), 
permettant d'interroger la base LDAP sur ses coordonnees geographiques. Ce 
principe de chainage (redirection) utilise les fonctionnalites du module « Broker » 
(voir figure 3). II est integrS dans le script de conversion XF via les variables de 
services. 

4.3. Structure d'un script de conversion XF 

Comme deja indique, le script de conversion XF se situe au coeur de la presente 
invention. On va presenter ici quelques unes de ses caracteristiques fondamentales. 

4.1.1 . Structure generate du script XF : Gabarits 

Un script de conversion XF se compose d'une liste de procedures, chacune d'entre 
elles etant applicable a des noeuds du document qui satisfont une condition bien 
definie, comme par exemple « etre un noeud de type 'paragraphe' du corps du 
document ». La condition et sa procedure associee sont appelees gabarits 
(« template »). 



On adopte dans la suite les designations suivantes : 
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Template A : pour tout noeud satisfaisant la condition A, faire (procedure A). 
Template B : pour tout noeud satisfaisant la condition B, faire (procedure B). 

5 Template Z : pour tout noeud satisfaisant la condition Z, faire (procedure Z). 

Sur le plan de la syntaxe, un script de conversion XF est lui-merne un document en 
langage balise. Chaque gabarit y est represente par une paire de balises ouvrante et 
fermante, signifiant respectivement le debut d'un nouveau gabarit et la fin de ce 
1 0 meme gabarit. La condition associee est rattribut de correspondance « Match » de la 
balise ouvrante ; la procedure a executer est le contenu compris entre la balise 
ouvrante et la balise fermante de l'element « template ». 

Ainsi, la clause « pour tout noeud paragraphe du corps du document , faire (procedure 
15 P) » s'ecrit de la facon illustree sur la figure 8. 

Cette syntaxe est inspiree de la syntaxe du langage XSL, mais la comparaison 
s'arrete la. D'abord, la syntaxe du critere « Match » est bien plus simple, comme on 
le verra plus loin. Ensuite, contrairement a l'element « gabarit » du langage XSL 
20 («xsl : template »), l'element gabarit de XF ne contient aucunes sous-balises. Le 
contenu de l'element gabarit est une procedure en langage ECMAScript appelee 
« procedure-gabarit ». 

4.3.2. Proerammation des procedures-gabarits 

25 

Les explications qui suivent sont faites en reference aux specifications ECMAScript 
et DOM, auxquelles on se referera pour tous les details necessaires. 

Chaque procedure-gabarit represente une methode d'un objet de la classe de noeuds 
30 Node, classe standard definie par « org.w3c.dom.Node » dans la specification DOM. 
Plus precisement, le sujet (« this ») de chaque procedure-gabarit est l'objet noeud de 



l'arbre DOM qui a satisfait la condition d'execution (Match). Toutes les methodes 
definies par DOM pour la classe Node sont applicables a l'objet sujet (« this ») de la 
procedure-gabarit. 

Par exemple, dans la procedure P suivante : 

XF. log. writeln (this . getNodeName ( ) ) ; 

qui est appelee pour tout paragraphe du document, l'appel de la fonction DOM 
« getNodeNameO » appliquee a l'objet « this » retourne le mot « PARA ». 

La description des operations en « liste de gabarits » est une approche 
particulierement bien adapts a la conversion d'arbre. Cependant, les traversers 
d'arbres et les recurrences qu'elle peut impliquer ne sont pas intuitives. En creant la 
notion de procddure-gabarit dont l'objet sujet («this») se trouve etre le noeud 
courant, la comprehension des effets induits est grandement facilitee. 

L'approche proposes selon la presente invention possede comme atout majeur une 
programmation naturelle de la conversion, qui conduit a un code relativement simple, 
lisible, qui ne necessite pas d'apprentissage tout en etant particulierement puissant. 

Le Script de conversion XF se compose done d'une liste de procedures-gabarits, 
chaque procedure etant decrite par la balise « template ». Pour que la conversion 
s'effectue, il faut maintenant proceder a l'execution de ces procedures, et Ton va 
maintenant d6crire la facon dont ces procedures sont appelees. 

4 11 Ap pel des procedures-gabarits 



C'est par la methode « applyTemplate(select) » que les procedures-gabarits sont 
appelees. Cette methode est une des methodes de l'objet global XF, et s'ecrit done : 
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XF. applyTemplate (select) 

La methode « applyTemplate » donne Fordre de rechercher et d'ex^cuter tout gabarit 
applicable aux noeuds de Tarbre rencontres pendant ia travers6e sp6cifi6e par la 
5 valeur de Pargument de selection « select ». Cet argument de selection est dite 
« Equation de travers6e ». 

Comme le critdre conditionnel d'execution « Match », l'equation de traversee utilise 
une syntaxe simple, proche de celle pr6n6e par le groupe de travail TEI (pour « Text 

10 Encoding Initiative » en terminologie anglo-saxonne). En effet; le langage de 
conversion XF ne n£cessite pas une selection complexe des noeuds. La puissance de 
ce langage XF provient naturellement de son aptitude a etre programme. Une 
programmation classique (operations conditionnelles de type « if... else », variables, 
boucles) permet d'exprimer ais6ment une solution algorithmique, et d'eviter que 

1 5 F equation de traversee et/ou la condition d'execution soient les seuls charges de cette 
responsabilite. (On notera ici que, si Ton tentait d'utiliser la syntaxe standard du 
langage XSL, on demontrerait Pinadaptation des Equations XSL k resoudre de reelles 
conditions de conversion : le degre de complexity des equations de correspondance et 
de selection augmenterait exponentiellement pour chaque nouvelle condition, 

20 necessitate des heures de travail sans certitude absolue de la validite de liquation 
obtenue). 

La methode « applyTemplate » engendre une veritable reaction en chaine. Ainsi, 
depuis la procedure-gabarit du noeud-racine du document, elle appelle toutes les 
25 procedures-gabarits selon l'equation de traversee. Les procedures-gabarits qui 
satisfont ia condition d'execution « Match » sont activees, et, & leur tour, peuvent 
lancer une methode « applyTemplate » qui appelle toutes les procedures de gabarits, 
etc. 

30 Ce mecanisme puissant etant parfois difficile a controler, on prevoit 
avantageusement selon F invention des routines de debogage du script ecrit, 
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specialement etudiees pour fournir les moyens rapides de corriger une erreur de 

recursivite. 

Pour que le dispositif de reaction en chaine demarre, la procedure-gabarit du nceud- 
racine du document doit etre appelee : Ce* la seule procedure qui soit appelee 
automatiquement. 

1 11 A imiTr— — ^« variables - clnHrrw, environnement de service 

Le langage de conversion XF fournit des fonctions qui permettent la communication 
de variables entre procedures-gabarits. Ces variables sont dites "cloitrees", c'est a 
dire qu'une procedure-gabarit peut creer son propre jeu de variables (dans son 
« cloitre »), variables qui seront heritees pax 1'ensemble des procedures-gabants 
qu'elle appelle. Une variable cree par un cloitre ne peut etre transmise au cloitre 
parent. 

Les variables cloitrees peuvent etre de toute nature: nombres entiers, chaine de 
caracteres, tableaux, et meme objets ECMAScript (augment appeles « Elements 
Dynamiques»), ce qui permet de d'etendre considerablement la puissance de ce 

m6canisnie. 

Une methode « applyTemplate » constitue en outre un moyen pour passer un nombre 
quelconque de variables par argument. 

. La duree de vie des variables cloitrees est le temps d'execution du script de 
conversion XF dans lequel elles sont defmies. Une session, cependant, comporte 
generalement plusieurs requetes et done plusieurs conversions qui peuvent avotr 
certaines variables en commun. Le langage de conversion XF foumit cette possib.hte 
par le biais de variables dites d' environnement de service. 



Initialises et reactualisees par le module « Broker » (voir plus haut), la valeur des 
variables d'environnement depend essentiellement du service appelant, et notamment 
du type de requ€te arrivant). Dans le cas de la transformation en code WML par 
exempie, l'identite de Tappelant et le module de telephone sont des variables 
enregistr^es dans Fenvironnement de service. 

4.3.5. Ecriture du docu me nt r&ultat 

La production du r6sultat est bien entendu une fonction fondamentale du script de 
conversion. La m6thode « XF.resultO » fournit un objet qui permet d'acc&ler au 
document en sortie. Par exempie, en donnant acc6s au nceud racine de ce document, 
l'ecriture du document en sortie revient a mettre en oeuvre les m6thodes d^finies par 
le module DOM pour ajouter des noesuds dans un arbre. Ces mdthodes d'accds 
al6atoire en ecriture coexistent avec la m&hode « XF.resultO. writeO » qui additionne 
simplement un morceau de iangage balise au flux de sortie. II faut noter que dans 
tout les scripts experimentaux r£alis6s dans le cadre du d6veloppement de la pnSsente 
invention, m£me les plus complexes, les m&hodes d'acces ateatoire ont 6tc rarement 
necessaires. 

4.3.6. Autres fonctions du Iangage de conversion XF 

Le Iangage XF peut fournir d'autres fonctions telles que : 

* recherche de texte par utilisation d' expression rdgulieres 

* niveau de trace de debogage, 

* instanciation d'objets Java, 

etant note ici que Ton a interet a limiter le nombre de m^thodes pour garder a ce 
Iangage sa simplicity et son pouvoir federateur. 

4.4. Exempie concret d'un script de conversion XF 
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Les extraits de code qui sont represent sur les figures 9 et suivantes illustrent 
certains des aspects decrits ci-dessus. Ces exemples ont et6 extraits d'une application 
de conversion reelle, a savoir la recherche d'horaires de vols d'avions et leur 
affichage sur un telephone WAP. 

Dans le cas particulier de cette conversion, applicable a de nombreux autres cas, 
1'analyse prealable du plan du site concerne de la Toile nous a amend a enoncer les 
regies suivantes (on omettra ici le choix de l'a6roport pas souci de simplification) : 

* la plupart des pages du site sont organises en « cadres » (« frames » en 
terminologie anglo-saxonne). Un tel cadre delimite une portion rectangulaire 
constituant une sous-partie de 1'ecran d'affichage de la page HTML. Introduit par la 
deuxieme gyration des logiciels standard de navigation, ce mecanisme concoit la 
page HTML comme une mosalque de cadres, collection de cadres ou « ensemble de 
cadres » (« frameset » en terminologie anglo-saxonne), chacun de ces cadres ayant 
une adresse HTTP qui lui est propre .Trouver Information recherche* a travers des 
cadres impose un examen du contenu de chacun d'entre eux. Pour toute page dans 
laquelle une balise « FRAMESET » est rencontree, la requete doit etre redirigee en 
demandant I'acces a la page corresponds a chacun des cadres composant 
1'ensemble de cadres. En g6neral, ces cadres sont cr66s dynamiquement par les 
programmes de type « cgi-bin » du site explore (dans le present exemple, les horaires 
sont mis a jour toutes les 3 minutes). Rien n'empeche que la page en retour ne 
contienne a nouveau une balise FRAMESET : il faut alors reiterer le processus. 

* Ces redirections doivent s'enchainer jusqu'a ce que l'on trouve (dans l'ordre) l'une 

5 des deux pages suivantes : 

- soit la page qui propose le choix : horaires de depart ou d'arrivee ; 

- soit la page du tableau des horaires (ce que Ton cherche). 

* Lorsqu'il est accede a la page « choix des horaires », le systeme propose ce choix 
sur le telephone, attend la reponse de 1'utilisateur, puis reprend le processus en 

10 orientant la recherche vers l'horaire desire (depart ou arrivee) 



) 
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* Lorsque la page des horaires est enfin trouvee, le systeme convertit le tableau au 
format HTML de la page dans un format approprie pour son affichage sur l'ecran du 
telephone. 

5 La conversion indiquee au dernier point ci-dessus est done assortie d'une logique de 
navigation prealable. Dans 1' architecture du convertisseur XGate, le module 
« Broker » est responsable de ces redirections successives. Pour ce qyi conceme le 
deroulement de la conversion, le module « Broker » n'est pas visible. Le script de 
conversion XF, appele pour toutes les pages auxquelles il est accede, y fait appel 
1 0 implicitement, de facon transparente et simple. 



4.4. 1 . Gabarit de base 

Etant ici rappele qu'un script XF est une suite de gabarits, le premier gabarit de ce 
1 5 script est represents sur la figure 9 des dessins. 

Ce gabarit est appele pour le noeud « HTML » de l'arbre du document d'entree. 
S'agissant d'une page de la Toile, ce noeud est le noeud-racine du document, faisant 
de ce gabarit un « gabarit de base », qui est le premier appele dans la liste des 
2 0 gabarits qui composent le script de conversion XF. 

Toutes les instructions specifiques a l'outil de conversion commencent par "XF.", 
qui, en langage Java, signifie que Ton refere une methode de l'objet XF. Cet objet 
fait implicitement de l'environnement du script. Par exemple, dans le corps du 
25 gabarit, l'instruction « XF.traceO » demande a l'objet XF de produire une trace de 
debogage dans les fichiers de contrdle du deroulement (fichier dit « log »). 

L'instruction « XF.applyTemplates(...) » demande au script d'appeler toutes les 
procedures-gabarits correspondant aux noeuds decrits par l'equation de traversee : 
30 « origin().descendant(all,(FRAMESET|BODY)) ». Cette equation utilise une syntaxe 
du type « XPointers ». Elle signifie : partant du noeud courant - « originQ » - 
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parcourir tous les noeuds qui en descendent - « descendant(all,...) » - et dont les 
noms sont soit « FRAMESET », soit « BODY » . 

En effet, comme enonce plus haut, seuls les noeuds dont le nom est « FRAMESET » 
ou « BODY » doivent etre pris en consid6ration dans le cas particulier de cette 
conversion. Les noeuds « FRAMESET » arretent la conversion pour demander 
l'acces a la page qu'ils referent ; les nceuds de corps « BODY » contiennent quant a 
eux des resultats a convertir et afficher. 

4.4.2. Chainaee des cadres : g aharit FRAMESET 

On va examiner tout d'abord le gabarit appele pour les noeuds FRAMESET, tel 
qu'illustrS sur la figure 10. 

La premiere instruction de cette procedure-gabarit, a savoir « XF.setVar("framed", 
1) », cree la variable cloitree "framed" en lui assignat la valeur 1. On en expliquera 
plus loin la raison. 

Les descendants directs (enfants) du nceud dont le nom est « FRAMESET » sont des 
noeuds dont le nom est « FRAME » : ce sont ces noeuds qu'il faut examiner afin de 
trouver celui qui decrit la page a laquelle il faut acceder. Ceci est effectue de la facon 
suivante : le modele DOM definit la methode « getChildNodesO » qui foumit la liste 
de tous les enfants d'un noeud donne. On sait que le sujet du script d'un template est 
le noeud DOM pour lequel ce template a ete appele : c'est l'objet « this ». La boucle 
de recherche de la page est done une boucle « for » classique en soi, qui est designee 
par la reference 101 sur la figure 10. 



Le modele DOM definit que la liste obtenue est un objet (ici de la classe standard 
« org.w3c.dom.NodeList ») dont la methode « item(i) » permet d'en extraire le i* me 
element. A l'interieur de la boucle « for », l'instruction designee en 102 sur la figure 
10 permet d'obtenir successivement tous les enfants du noeud « FRAMESET » (a 



savoir les noeuds « FRAME »), jusqu'a ce qu'il n'en reste plus (la variable « child » 
prend alors la valeur « null ») ou que le noeud « FRAME » en question soit celui que 
Ton recherchait. 



Quant aux criteres utilises, l'examen du script de la figure 10 montre que seuls les 
cadres nommes : « HOME », « MainMenu », « Content », ou « Result » doivent etre 
sujets * une operation de redirection. C'est cet ensemble de conditions qui, 
exprimees par les instructions « if (...) » du script de la figure 10, vont piloter 
P operation de redirection. 

On notera ici que les noms de ces cadres dependent du choix du programme du site, 
qui peut evoluer avec le temps, mais Ton peut en general tabler sur le fait que les 
noms des cadres risquent moins d'etre modifies que d'autres elements des pages. Le 
choix de criteres bases sur les noms des cadres semble done etre le meilleur. En 
outre, on pourra imposer a Padministrateur d'un site de ne pas effectuer de 
modifications qui pourraient compromettre le fonctionnement du script de 
conversion, sachant que Pobligation de figer un nom de cadre n'est pas pour lui une 
contrainte reelle. Ainsi une telle contrainte ne gene pas les evolutions futures du site 
dans le temps, et les adaptations necessaires du script de conversion restent aisees. 

La redirection est declenchee par Pinstruction « XF.redirectTo(. . .) », methode qui 
prend en parametre Padresse HTTP de la nouvelle page. Cette adresse est la valeur 
de Pattribut « sre » du noeud « FRAME », obtenu par la methode « getAttributeO » 
appliquee dans le modele DOM au noeud « child » courant, a savoir le cadre. 

La redirection vers une autre page relance le script de conversion avec les donnees 
(Parbre en specification DOM) de la nouvelle page. Par defaut, le meme script de 
conversion est appele. (On notera ici que le module « Broker » permet de gerer 
plusieurs scripts a la fois. Ainsi la methode « XF.redirectToO » comporte un 
parametre optionnel indiquant, si besoin est, le nom du script XF qui doit etre 
execute. Ce nom est la valeur de Pattribut « name » de la balise-racine <xf:doO qui 



34 



preside a tout script XF. En terminologie XF, un changement de script s'appelle 
« changement de mode ». Allie au chargement dynamique de fichiers de conversion 
«XF.load()», la possibility de script multiples (gSres par le module « Broker » 
donne une souplesse remarquable dans 1' administration des conversions.) 

La navigation de ncsud « FRAME » a naud « FRAME » se poursuit jusqu'a ce 
qu'on accede aux pages -rtinentes. Ces pages ne component pas de 
« FRAMESET » et leur balise «BODY» contient les informations que Ton 
recherche. 

4.4.3. Conversion • paharit BODY 

Le gabarit « BODY » est illustre sur la figure 1 1 des dessins. 

15 En premier lieu, les instructions indiquees en 111 et 112 sur la figure 11 emvent 
dans le fichier de resultat respectivement le prologue et Epilogue communs a tout 
document WML. Utilises frequemment, les variables « prolog » et « epilog » sont 
definies une fois pour toutes par le programmer comme des chaines de caracteres 
(« string ») fixes. 
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Notons que l'execution de ce gabarit est conditionnee par l'examen de la variable 
« framed » ; c'est l'instruction designee par la reference 113 en figure 11. 

Si cette condition est vraie, alors on salt que ce nceud « BODY » n'est pas dans une 
page ; en effet, s'il en avait et6 autrement, le gabarit « FRAMESET » aurait cree la 
variable « framed » (qui n'aurait done pas la valeur null). 



Le corps BODY d'une page formee de cadres est sans interet pour la presente 
conversion. Plus precisement, dans le langage HTML, une balise BODY peut suivre 
3 0 la balise FRAMESET, mais le contenu de ce BODY est dans ce cas sans interet, car 
il est utilise par les logiciels de navigation datant d'avant l'epoque oi. le mecanisme 
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de cadres a ete introduit. Le plus souvent, une telle balise BODY affiche un texte 
indiquant F incapacity du logiciel de navigation k traiter des documents comportant 
des cadres. 

5 Dans ce cas, aucune autre instruction de ce gabarit n'est ex6cut6e. Aucun autre 
gabarit n'6tant actif, la conversion est termin^e 4 ce stade. 

Dans le cas contraire, cette page contient soit le menu de Pa&oport, soit Pun des 
horaires demands. L'examen de Paddresse HTTP (URL) de la page permet de 
10 Pindiquer : dans le present exemple, si la page contient « HomePage », il s'agit du 
menu ; si elle contient « DayFlight », alors il s'agit d'un horaire. 

L'adresse de la page courante fait partie des variables d'environnement : on Pobtient 
par la m&hode XF « getURL() ». Cette m&hode produit une chaine de caract&res - 
15 et plus precis&nent un objet ECMAScript de la classe standard « String » - dont la 
m&hode « indexOf 0 » permet de connaitre s'il contient ou non la chaine de 
caracteres « DayFlight ». 

Si c'est le cas, la page contient les horaires, sous forme de tableau HTML : il 
20 convient d'examiner le corps de ce tableau, c'est a dire le noeud nomm6 TBODY 
(pour.« table body »), quelque part dans la descendance du no&ud BODY sujet de ce 
gabarit. C'est ce qu'indique P6quation de navigation designee par 114 sur la figure 
11. 

2 5 4.4.4. Navigation hypertexte 

La conversion du tableau des horaires sera d6crite plus loin. En premier lieu, on 
examine le contenu de la clause « else » designee par la reference 1 1 5 sur la figure 
11, correspondant au cas ou Padresse de la page ne contient pas la chaine de 
30 caracteres « DayFlight ». 



Dans ce cas, il s'agit done de la page d'accueil de 1'aeroport. L' intervention de 
1'appelant au telephone est alors necessaire : veut-il les horaires de depart? 
d'arrivee ? II faut proposer ces deux choix, et, selon la reponse, naviguer vers la page 
adequate. Sur un tel6 P hone WAP, ce result* est obtenu par 1'envoi de la page en 
langage WML telle qu'illustree sur la figure 12. 

La proce4ure-gabarit appelante (gabarit BODY) a deja ecrit le prologue de cette page 
WML et en ecrira l'epilogue au retour. II faut done generer les deux lignes 
comportant la balise <a>, e'est-a-dire greffer sur l'arbre de sortie deux nceuds ayant 

des balises <a>. 

Les balises <a> sont les points d'ancrage de la navigation hypertexte. Leur syntaxe 
WML est tres proche de la syntaxe HTML, si ce n'est que la syntaxe WML impose 
la lettre « a » minuscule. Lorsque 1'appelant activera le mot « Departs » affiche sur 
son telephone WAP, il declenchera une navigation vers la page qui se trouve a 
l'adresse HTTP « ddddd ». 

Les valeurs des attribute href : »http://dddd» et "http://aaaaa" sont bien entendu 
donnees a titre illustratif. Dans la realite, il s'agit des adresses HTTP des pages de la 
Toile qui vont permettre de poursuivre la navigation vers les horaires soit de depart, 
soit d'arrivee (respectivement). Ces valeurs apparaissent dans la page HTML en 
cours de conversion comme etant I'attribut source des balises <A> dans le code 
HTML de la page, qui sont done des nceuds de l'arbre dans la descendance du nceud 
courant « BODY ». 

On utilise la lettre « A » majuscule pour la balise HTML pour bien differencier la 
balise a rechercher dans la page HTML du document d'entree de la balise WML <a> 
qui doit etre generee dans l'arbre de sortie. 

0 11 faut nontenant localiser les no^uds dont les balises sont <A>. L'examen du code 
de la page HTML conduit a remarquer que de tels noeuds ont comme enfant un noeud 
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de type « IMG » (une image) dont l'attribut « src » contient le mot « DEPART » ou 
le mot « ARRIVEE ». II faut done d'abord examiner tout les noeuds « IMG », c'est-a 
dire appliquer les gabarits aux descendants de type « IMG », ce qui s'ecrit comme 
indique a la deuxieme ligne de 1' instruction 1 1 5 de la figure 11. 

Le gabarit associe a ces noeuds images est illustre sur la figure 13. On notera ici que, 
dans !■ pratique, l'equation de correspondence « match="IMG" » pourra etre plus 
complexe en restreignant les noeuds candidats IMG a seulement ceux dont le pere est 

un noeud de type A. 

Par rapport a ce qui precede, il n'y pas reellement de notion nouvelle introduite par 
ce gabarit, si ce n'est l'appel a la fonction « addAnchorO »• 

Cette fonction n'est pas la m6thode d'un objet (sinon, sa syntaxe serait 
15 « sujet.addAnchorO »)• Ce n'est pas non plus une instruction definie par 
ECMAScript. En effet, il s'agit d'une fonction dite « locale », definie par le 
programmeur du script XF en question. 

On notera ici que de telles fonctions locales (ou routines) sont un outil precieux pour 
20 le programmeur a des fins de saturation, de ^utilisation et de lisibilite du code. 
Les scripts XF offrent en eux memes cette possibilite. Ces routines, qui peuvent etre 
appelees depuis n'importe quel gabarit, apparaissent dans le contenu de la balise : 
<xf :script>. Cette balise complete la liste des balises apparaissant dans le script XF. 
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On notera ici qu'il existe dans le present exemple une autre balise, <xf:init>, qui 
apparait dans un seul script XF, a savoir le script "par defaut". Le script XF par 
defaut est un script dont la balise-racine <xf:doO ne possede pas d'attribut de nom 
"name", ou, s'il existe, possede un tel attribut dont la valeur est le nom reserve 
«#default". Le script par defaut est appele lorsque le mode courant n'est pas defini. 
La balise <xf:init> definit alors la procedure de conversion a appliquer lorsque le 
document source a convertir n'existe pas. C'est ce qui se produit lors du premier 
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contact avec un nouvel appelant au telephone - d'ou le nom « init ». C'est aussi ce 
qui peut se produire en cas d'erreur de navigation (code HTTP 404). 

Un nombre quelconque de routines locales ou de variables locales peuvent 8tre 
dSfinies. On y trouvera par exemple les variables locales chaines de caracteres prolog 
et epilog qui ont 6t6 eVoquees plus haut. 

Dans le cas d'espece, 1'eTement « xf rscripts » contient la fonction « addAnchorO » et 
se presente de la facon illustree sur la figure 14. 

Le rdle assigne par le programmeur a cette routine est de construire un point 
d'ancrage : 1' activation de ce point depuis le telephone WAP entrainera la navigation 
vers la page desiree de la Toile, ici les horaires de depart ou les horaires d'arrivee. 

Cette routine contient une boucle qui recherche le premier nceud « A » dans la lignee 
parentale du noeud « IMG » courant. Lorsque ce noeud a ete trouve\ la routine appelle 
la m&hode « XF.resultO writeAnchorO »• 

On va decrire le rdle de cette methode en la decomposant. 

Tout d'abord, la methode «XF.resultO» permet d'acceder au fichier resultat, a 
savoir le document qui sera envoys vers le telephone WAP. II s'agit ici d'une 
ecriture sequentielle, mais comme on l'a vu plus haut, il existe d'autres moyens pour 
ecrire ce fichier resultat, tels qu'une ecriture en acces aleatoire, a savoir l'ajout d'un 
noeud de Tarbre DOM de sortie. 

Ensuite, la methode « writeAnchor() » de l'objet « fichier resultat » obtenu par la 
methode « XF.result() » possede comme premier argument le texte du point 
d'ancrage associe a la reference hypertexte : « Departs », ou « Arrivees ». Le second 
argument est la reference hypertexte, obtenue par la lecture de la valeur de l'attribut 



« href » du noeud parent de balise <A>. Le troisieme argument est la reference locale, 
qui est le nom qu'il faut associer a la reference hypertexte. 



Des exemples de valeurs de ces trois arguments sont illustres sur la figure 1 5. 
pour obtenir le resultat, on ecrit dans le fichier de sortie : 
<a href="/xxx/airport.21">D6parts</a> 

«xxx» identifiant la session (l'appelant), « airport » identifiant le mode de 
transformation (<xf :doc name = "airport">, et « 21 » identifiant l'6tape. Sans entrer 
dans les details, c'est le role du module « Broker » de reconstituer l'adresse reelle de 
la page qui fournit le r&mltat et d'indiquer les autres references (appelant, mode, 
etc..) via les variables d'environnement du script de conversion XF appele pour la 
conversion de cette page. 

4.4.5. Affichage du tableau des horaires 

On va maintenant decrire la conversion du resultat, a savoir le tableau des horaires 
des vols qui correspond au noeud TBODY. 

On indique tout d'abord une representation de l'arbre du document a ce noeud. C'est 
la une description classique de la structure commune a tout tableau d'un document 
HTML. Cette representation est illustree sur la figure 16. 

Les enfants du noeud TBODY sont les lignes de la table (noeud TR) . Chacune de ces 
lignes correspond ici a un vol. Les noeuds TR ont pour enfant des noeuds TD qui 
reprisentent les colonnes de la table. A leur tour, les noeuds TD ont pour descendants 
le texte meme de chacune des colonnes. Ce texte donne les caracteristiques du vol. 
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On notera ici que le lien de descendance entre un noeud TD et le texte associe peut- 
etre indirect, avec, par exemple, Intervention d'un noeud indiquant la police de 
caractere utilisee. 

5 Pour atteindre le texte de chacune des colonnes, on utilise done l'equation de 
navigation : 

origin ( ) . child ( i ) . descendant (all , #text ) 

10 « i » etant une variable indiquant le numero de la ligne. Cette equation signifie : 
partant du noeud courant TBODY - "originO" - atteindre le ieme noeud-enfant TR - 
"child(i)" - et appliquer le gabarit correspondant a tous les descendants de type text - 
"descendant(all,#text)" . 

15 Le gabarit TBODY utilise done une boucle d'iteration sur toutes les lignes de la table 
et s'ecrit de la facon illustree sur la figure 17. 

Dans la realite, il peut se produire que les lignes du tableau ne contiennent pas 
uniquement les renseignements afferents a chaque vol. Ainsi dans le present 
20 exemple, certaines lignes sont utilisees pour la mise en page : elles sont reperees par 
un fond blanc, et sont suivies de 2 lignes de titre. C'est ce qui est repercute dans le 
script par la condition designee par la reference 171 sur la figure 17. 

Les lignes qui nous interessent font l'objet d'un appel a la procedure-gabarit chargee 
25 de la mise en forme du contenu des colonnes (les descendants de type texte). C'est le 
role de l'instruction designee par la reference 172 sur la figure 17. 

Le premier argument de la methode « applyTemplates » est l'equation de navigation 
indiquee plus haut. II existe un second argument « data ». Cet argument optionnel est 
30 passe tel quel a toutes les procedures-gabarits appliquees. 
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Pour cet argument « data », le programmeur de ce script a choisi un objet charge de 
collecter les renseignements contenus dans chaque Hgne du tableau. C'est un objet 
ECMAScript classique, cre6 classiquement par l'operateur « new » et designe par la 
reference 173 sur la figure 17. 

5 

La definition de l'objet « FlightData » est locale - il est cree par le programmeur du 
script XF - et se trouve done dans le contenu de la balise : <xf :scripts>. S'agissant 
d'un dispositif standard d'ECMAScript, on n'entrera pas ici dans le detail de la 
construction de cet objet. II suffit d'indiquer que l'objet FlightData fournit les 

10 methodes pour collecter les informations associees a chaque Hgne decrivant un vol : 
date, heure, aeroport, num6ro du vol, compagnie, etc. En passant cet objet a la 
procedure gabarit de tout noeud de type texte de la ligne du tableau, chaque champ de 
l'objet « data » sera complete au fur et a mesure. Lorsque tous ces procedures auront 
ete appliquees, a savoir que la methode « applyTemplateO » est terminee, 

15 r instruction designee par la reference 174 sur la figure 17 produira sur le fichier de 
sortie le contenu textuel ainsi collects. 

La procedure-gabarit pour chaque portion de texte s'ecrit simplement de la facon 
illustree sur la figure 18. 

20 

4.4.6. Resultats 

La figure 19 montre le resultat obtenu sur un telephone WAP de marque Nokia, en 
parallele avec les informations correspondantes identiques affichees sur un 
2 5 navigateur de Toile standard. 

4.4.7. Trace de controle 
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La trace de controle (« log » en terminologie anglo-saxonne) est un fichier de 
controle qui permet de suivre les etapes de la transformation. La trace generee pour 
l'exemple qui vient d'etre decrit comprend les elements suivants : 
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- conversion 1 : enregistrement des messages de corrections de l'analyseur 
syntaxique ; le resultat de la conversion est une redirection (figure 20) ; 

- conversion 2, 3 et 4 : autres redirections (figures 21 a 23 respectivement) ; 

- conversion 5 : la page d'accueil de l'aeroport a ete trouvee ; le script de conversion 
5 XF renvoie une page au format WML vers le telephone WAP ; cette page comporte 

deux liens hypertexte, respectivement vers les Departs et vers les Arrivees. On notera 
ici la constriction « $(sid) » qui permet d'identifier l'utilisateur entre chaque requSte. 
La notation « $(x) » est quant a elle typique des te^phones WAP : elle indique une 
reference a la variable interne « x » que XF a genere dans l'electronique du 
10 t61ephone. Le telephone se connait et s'identifie aupres du module « Broker » du 
convertisseur XGate (figure 24) ; 

- conversion 6 : l'utilisateur du telephone s'interesse aux departs ; cette information 
necessite une redirection (figure 25) ; 

- conversion 7 ; nouvelle redirection (figure 26) ; 

15 - conversion 8 et fin : le tableau des horaires de depart a 6te convert! au format 
WML, et est envoy<§ au telephone WAP (figure 27). 

4.5. Definition formelle du documen t XF : DTP 

20 Comme on l'a vu plus haut, le script de conversion XF est encapsule dans un 
document balise XML. A ce type de document correspond doit done correspondre 
une « Description Technique de Document » (DTD) qui est representee sur la figure 
28. 

2 5 Bien entendu, la presente invention n'est nullement limitee aux formes de realisation 
decrites ci-dessus et representees sur les dessins, mais l'homme du metier saura y 
apporter de nombreuses variantes et modifications. 

En particulier, l'homme du metier saura adapter les principes de 1' invention aux 
30 nouvelles specifications susceptibles d'apparaTtre dans la definition des documents 
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echanges par un reseau tel que l'Internet, dans la programmation et dans la 
modelisation d'objets, etc. 
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R F.VRNDIC ATIONS 



1. Systeme de conversion de documents, destine a transformer un premier 
document existant dans un premier format balise a structure arborescente de nceuds 
en un second document dans un second format balis6 a structure arborescente de 
noeuds, caracterise en ce qu'il comprend : 

un ensemble de procedures-gabarits (Template), chaque proc&iure-gabarit 
dudit ensemble contenant une premiere information de selection d'une Vendue de 
parcours de la structure arborescente du premier document, une seconde information 
de selection d'un type de balise du premier document auquel la procedure gabarit 
peut s'appliquer, et un ensemble d'une ou plusieurs actions, au moins certaines 
procedures gabarits contenant des actions de collecte d' informations delimitees par 
les balises dont le type correspond a celui defmi par la seconde information de 
selection de ces procedures gabarits, 

un programme contenant des instructions standard (applyTemplates) pour 

selectivement appeler lesdites procedures gabarits, 

des moyens de traitement r^pondant audit programme et aptes, lors de 
l'appel d'une procedure-gabarit, a parcourir les nceuds de la structure arborescente 
inclus dans son etendue telle que deTinie par la premiere information de selection de 
ladite procedure-gabarit, et pour chaque noeud parcouru, a determiner si le type de 
balise correspondant audit noeud correspond a la seconde information de selection et, 
dans l'affirmative, a exercer la ou les actions correspondantes, et 

des moyens aptes, a partir des actions de collecte contenues dans les 
procedures-gabarits executees, pour construire le second document. 

2. Systeme selon la revendication 1, caracterise en ce que les actions d'au 
moins certaines procedures-gabarits contiennent des instructions d'appel d'autres 
procedures gabarits. 
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3. Systeme selon la revendication 2, caracterise en ce que la premiere 

information de selection d'etendue d'une procedure-gabarit est basee sur un noeud de 
depart constitue par le noeud a partir duquel ladite procedure-gabarit est appelee. 

5 4. Systeme selon l'une des revendications 2 et 3, caracterise en ce qu'au moins 
certaines procedures-gabarits contiennent des actions de creation de variables 
temporaires cloitrees, et en ce que chacune de ces variables cloitrees est herite%par 
toute procedure-gabarit appelee par de telles proceclures-gabarits. 

10 5. Systeme selon l'une des revendications 1 a 3, caracterise en ce que les 
procedures-gabarits comprennent une procedure-gabarit de base possedant la 
seconde information de selection correspondant a un noeud racine de la structure 
arborescente du premier document, et en ce que les actions de ladite procedure- 
gabarit de base comprennent un appel de procedures-gabarits. 

15 

6. Systeme selon la revendication 5, caracterise^ en ce que les actions de ladite 
procedure-gabarit de base comprennent un appel de procedures-gabarits dont la 
seconde information de selection correspond a un type de balise « corps ». 

20 7. Systeme selon la revendication 6, caracterise en ce que la structure 
arborescente de nceuds du premier document comprend des noeuds de type « cadre », 
et en ce que les actions de ladite procedure-gabarit de base comprennent un appel de 
procedures-gabarits dont la seconde information de selection correspond a un type de 
balise « ensemble de cadres ». 

25 

8. Systeme selon l'une des revendications 1 a 7, caracterise en ce qu'au moins 
certaines procedures-gabarits comprennent au moins une action de redirection vers 
un premier document different, sur lequel lesdits moyens de traitement sont 
appliques sur la base du meme programme. 
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9. Systeme selon Tune des revendications 1 a 8, caracteris6 en ce qu'au moins 
certaines procedures gabarits comprennent au moins une action conditionnelle basee 
sur le contenu d'une adresse d'accfes au premier document. 

10. Systeme selon Fune des revendications 1 a 9, caracterise en ce qu'au moins 
certaines proc&iures-gabarits comprennent au moins une action constituant une 
m&hode d'un objet et/ou au moins une action constituant une fonction locale 
programme. 

11. Systeme selon la revendications 1 a 10, caract&ise en ce que certaines 
procedures-gabarits comprennent une fonction locale d'ancrage apte k convertir une 
requSte adaptee a la structure du second document en une adresse d'un premier 
document contenant Finformation recherch6e. 

12. Systeme selon Tune des revendications 1 a 11, caracterise en ce que les 
moyens de construction du second document comprennent des actions d'6criture 
contenues dans certaines proc6dures-gabarits dont la seconde information de 
selection dSfinit une balise a contenu, lesdites actions d'6criture 6tant aptes k 
assembler de fa?on pr£d&erminee au moins une partie des contenus desdites balises. 

13. Systeme selon Time des revendications 1 a 12, caracterise en ce que les 
premiers documents comprennent des pages structurees dans un langage balise 
standard adapt6 k une consultation sur poste informatique client via F Internet et en ce 
que les seconds documents comprennent des pages structurees dans un second 
langage balise standard adapte a une consultation sur appareil miniature portable. 

14. Systeme selon Fune des revendications 1 a 13, caracterise en ce que les 
moyens de traitement et de construction du second document operent en mode 
dynamique au cours d'une session entre un appareil apte a afficher des informations 
dans la structure des seconds documents et un serveur apte a foumir des informations 
dans la structure des premiers documents. 



15. Systeme selon Pune des revendications 1 a 14, caracterise en ce qu'il 
constitue un gradin d'une architecture multi-gradins. 



16. Architecture informatique multi-gradins, caract6ris6e en ce qu'elle 
comprend en succession, relics par r6seau informatique, un premier gradin de 
consultation de dories sur poste-client, un second gradin duplication sur serveur, 
un troisteme gradin d'aggregation de donnees comprenant un systeme de conversion 
selon Tune des revendications 1 k 14 et un quatrteme gradin comprenant une 
pluralite de types de sources de donnees ind6pendantes. 

17. Architecture selon la revendication 16, caract6ris6e en ce que la plurality de 
types de sources de donnees ind^pendantes comprennent au moins deux types de 
sources parmi les serveurs Internet, les serveurs d'annuaires k accds rapide et ies 
serveurs de bases de donnees k acces standard par requetes. 

18. Architecture informatique/t61ephonique multigradins, caract6ris<Se en ce 
qu'elle comprend en succession, relies par r6seau informatique et par rSseau 
tetephonique sans fil, un premier gradin de consultation de donnees sur un appareil 
portable tel qu'un telephone portable, un second gradin de transport de donn6es sans 
fil, un troisieme gradin comprenant un systeme de conversion de documents selon 
l'une des revendications 1 a 14 et un quatri&ne gradin comprenant au moins un type 
de source de donn6es. 

19. Architecture selon la revendication 18, caracterise en ce que ledit type de 
source de donnees consiste en des pages structures dans un langage balise standard 
adapte a une consultation sur poste informatique client, lesdites pages constituant des 
premiers documents, et en ce que le systeme de conversion compris dans le troisieme 
gradin est apte a construire des seconds documents dans un second langage balise 
standard adapte a une consultation sur appareil miniature portable. 
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<xf: template match=£)PO> 
(procedure P) 
</xf : template> 
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<xf: template match="HTML"> 
XF. trace () ; 

XF.applyTemplates ("origin ( ) .descendant (all, (FRAMESET | BODY) ) " ) ; 
</xf : template> 
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<xf : template match=" FK/^LbET' 
XF . se tVa r ( " f ramed" , 1 ) ; 



[var list = this . getChildNodes ( ) 




for (var i^O; ;++i) {f ~ 
/ fvar child - list . item ( i ) ; 
if (child == null) break; 
if (child. getNodeName () -= " FRAME" ) ( 

var name = chi ld . getAt.t ribute ( "name" ) ; 
if ( 

((name ==.null) (child. getNextSibling ( ) null)) M 

(name == "HOME" ) II (name « "MainMenu") II 
(name — "Content") tl (name == "Result") 

) { 

XF. redirectTo(child.getAttribute("src") ) ) ; 
break; 

) 



</xf: 
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.vf-tpr^l.te name-"body" match== "BODY"> 4^ S 
fTf (null — XF.getVaFrframed") )_ { J T 

rxF.resultO . write (prolog)"T) 

var url = XF \getURL ( ) j_ 



J I result 



Tndextffl "DayFlight" ) > 0) 

/ j else l \ — — . 

^■ ^XF.applyTemplates ("origin () ■ descendant (all , IMG) " ) 



CxF.resultO . write (epilog) 7) , 



</xf : template> 
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<?xml version= 


\"1.0\"?> 




<!DOCTYPE wml 


PUBLIC "-/ /WAPFORUM//DTD WML 1.1//EN" 




<wml> 


"http: //www. wapfo rum. org /DTD /wml 1 . 1 .xml\"> 


* prologue 


<card> 






<p> 






<a href="http: 


/7ddddd " > De par t s < 7 a > 




<a href="http: 


//aaaaa">Arriv^es</a> 




</p> 
</card> 




► epilogue 


</wml> 







CABINS REG/MBEAU 

D ^PL/CATA 




13/28 




V 



FIGURE 13 



<xf: template name="menultem" match= M IMG "> 
var text = this . qetAtt ribute ( "src" ) ; 
if (text. indexOf ("DEPART") > 0) { 

addAnchor (this, "Departs", "airport. 2 
jelse if (text. indexOf ("ARRIVE") > 0) { 

addAnchor (this, "Arrivees", "airport. 

> 

</xf : template> . 
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<xf :scripts> ~ 

function addAnchor (node, text, localRef) { 

while (null (node = node . getParentNode ( ) ) ) { 

if (node . getNodeName () == 1 A ' ) { 

XF. result () .writeAnchor (text, node . getAtt ribute ( "href " ) , 1 



break; 



</xf : scripts> 
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Sfhypcrtexte httpTwww.montpel.ier.aeroport.fr/cgi-bin/WebObjects.dU^ 
Ref locale airport.21 
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Affichage du tableau des horaires 
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<xf: template match="TBODY"> 

var list * this . getChi ldNodes ( ) ; 
for (var i=0; { 
child = list . item (i) ; 

child == null ) break s 

if 



^ Cl 1J. J. Li null ; vj LKzaj^f — — ^ 

(child. ge ^Attr j -buteT" bgc olor" ) « " FFFFFF" ) { / / irrelevant ) 
felse_J_ ^ ^ y |'}~3 



var data = new FlightPat a { ) ; 
XF. appl'y'T emplates"( \^ 
'originO .child( M 



+ i + ") . descendant (all, If text ) ' 



/data/ 




r rj — i - — s 

STFTresult ()- write (data . time From + "<br/>" + data . others) ; ) 



</xf : template> 
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La procedure template pour chaque portion de texte s'ecrit simplement: 



<xf: template name=" flight" raatch=" text ( ) "> ' " " " 

var text « this I getNodeValue (). reduce () ; 
if (text. length > 0) { 
var i = argO . item++; 

If ii T t 1) { o ar 9°-timeFrom = text + « // arrival time 

else if (i 2) argO.timeFrom += text; // from 

else if (i == 3) argO. others - «.« + text + "<br/>"; // airline 

else if (i == 4) argO. others += «.« + text + "<br/>"; // buildg 

else if (i ™ 5) argO, others +« ■• . " + text + "<br/>»; // remarks 

^ else if (i 6 ) argO. others +- + text + "<br/>»; // departure time 

</xf : template> 
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[Jun 17 12:38:S5 CEST 2000] Service-47 started 

Uun 17 12:38:55 CEST 2000] Service-47, Proxy: plain copy tJ _ n/1 rt 

(Jun 17 12:38:55 CEST 2000] Service-47-in : GET http://www.Nantes.aecoport.fr HTTP/1.0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset: ISO-8859-1, UTF-8 

host: www.Nantes.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 17 12:38:56 CEST 2000] Service-47-out : HTTP/1.0 200 OK 
content-type: text/html 
date: Sat, 17 Jun 2000 09:42:47 GMT 
last-modified: Fri, 12 May 2000 14:53:47 GMT 
accept-ranges : bytes 

link: <http: //www. aeroport . f r/?PageServices>; 
content-length; 5932 
server: Netscape-Enterprise/3 . 5. 1 



rel^'PageServices* 



[Jun 17 12:38:56 CEST 2000] Service-47-out , Xform: parsing... 
Cannot start element "META" : a required element is missing in BODY 

line 3, col 76 OOC o 

CONTENT^" text /html; charset=iso-88 by- 



required element is missing in BODY 



1">' 

in: " — 

at: > 

Cannot start element. "META" 

line 4, col 451 ... . 

in: 're, terminal, piste, runway, fret aenen, air _^®^^_^ 

Cannot start element "META": a required element is missing in BODY 
line 5, col 403 

in: 'mercial services, tourism in the Aquitame region _ > 

at: > ~ 

Warning: invalid end tag: "HEAD" 
line 5, col 413 

in: * rvices, tourism in the Aquitaine region 

at: > 

Warning: invalid end tag: "NOFRAMES" 
line 60, col 12 
in: 1 </nof rames> 1 
at: ■>- 



</head>' 



</head>' 



[Jun 17 12:38:57 CEST 2000] Service-47-out , Xform: 
[Jun 17 12:38:57 CEST 20001 Service-47-out , Xform: 
[Jun 17 12:38:57 CEST 2000] Service-47 ended 
[Jun 17 12:38:57 CEST 2000] Captured response ---- 
HTTP/1.0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text /vnd . wap . wml ; cha rset=ISO-8859- 1 
date: Sat, 17 Jun 2000 09:42:47 GMT 
last-modified: Fri, 12 May 2000 14:53:47 GMT 
accept-ranges: bytes 

link: <http: //www. aeroport . f r/?PageServices> 
server: Netscape-Enterprise/3. 5. 1 



transforming . 
done . 



rel=" PageServ ices' 



imbeau 



9J Jp Ll„ 

I original 
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FIGURE 21 



0 



[Jun 17 12:38:58 CEST 2000] Service-48 started 

[Jun 17 12:38:58 CEST 2000] Service-48, Proxy: plain copy 

fJun 17 12:38:58 CEST 2000] Service-48- in : GET 

ItTp://^ HTTP/1.0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset: ISO-8859-1, UTF-8 

host: www.nantes.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 17 12:38:59 CEST 2000] Service- 48-out : HTTP/1.0 200 NeXT 

content-type: text/html 

date: Sat, 17 Jun 2000 09:42:49 GMT 

content-length: 321 

server: Netscape-Enterprise/3 . 5. 1 

[Jun 17 12-38:59 CEST 2000] Service-48-out , Xform: parsing... 

[Jun 17 12:38:59 CEST 2000] Service-4 8-out , Xform: transforming... 

fJun 17 12:38:59 CEST 2000] Service-48-out , Xform: done. 

[Jun 17 12:38:59 CEST 2000] Service-48 ended 

[Jun 17 12:38:59 CEST 2000] Captured response 

HTTP/1.0 302 Redirected by transform 

location: http://xgate.jaxo.com/gjm/airport.rd 

content-type: text /vnd . wap . wml ; charset-ISO-8859- 1 

date: Sat, 17 Jun 2000 09:42:49 GMT 

server : Netscape-Enterprise/3 . 5 . 1 
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[Jun 17 12:38:59 CEST 2000) Service-49 started 

[Jun 17 12:39:00 CEST 2000] Service-49, Proxy: plain copy 

r Tnn 17 12-39-00 CEST 2000] Service-4 9- in : GET '! i 

http- //wwh! nantes . aeroport . f r/scr ipts/WebObjects/Uccega/NTE . woa/2093200000268020000023311 
00000536431/Main. wo/71921000004 364 31/1/1/Mermoz HTTP/1.0 

accept : text/html 
proxy-connection: Keep-Alive 
accept-charset: ISO-8859-1, UTF-8 
host: www.nantes.aeroport.fr 
user-agent: JaxoXform (1.25) 

[Jun 17 12:39:05 CEST 2000] Service-4 9-out : HTTP/1.0 200 NeXT 

content-type: text/html 

date: Sat, 17 Jun 2000 09:42:52 GMT 

content-length: 490 

server: Net scape-Enterprise/ 3 . 5. 1 

[Jun 17 12:39:05 CEST 2000] Service-4 9-out , Xform: parsing... 
[Jun 17 12:39:05 CEST 2000] Service-4 9-out, Xform: transforming... 
[Jun 17 12:39:05 CEST 2000] Service-49-out , Xform: done. 
[Jun 17 12:39:05 CEST 2000] Service-49 ended 

(Jun 17 12:39:05 CEST 2000] Captured response 

HTTP/1.0 302 Redirected by transform 
location: http: / /xga te . j axo . com/g jm/a i rport . rd 
content- type: text /vnd. wap . wml ; charset=ISO-88 59-l 
date: Sat, 17 Jun 2000 09:42:52 GMT 

server: Netscape-Enterprise/3 . 5. 1 _ _ 
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[Jim 17 12:39:05 CEST 2000] Service-50 started 

(Jun 17 12:39:06 CEST 2000] Service-50, Proxy: plain copy 

(Jun 17 12:39:06 CEST 2000] Service-50-in : GET 

http: //www.aeroport. f r /Uccega/NTE/Html /FR/HP/home . htm HTTP/1 .0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset : ISO-8859-1, UTF-8 

host: www.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 17 12:39:10 CEST 2000] Service-50-out : HTTP/1.0 200 OK 

content-type: text/html 

date: Sat, 17 Jun 2000 09:42:57 GMT 

last-modified: Wed, 17 May 2000 16:10:48 GMT 

accept-ranges : bytes 

link: <http: //www.aeroport. f r/Uccega/NTE/Html/FR/HP/home . htm?PageServices> ; 

rel="PageServices" 

content-length: 507 

server : Netscape-Enterprise/ 3 .5.1 

[Jun 17 12:39:10 CEST 2000] Service-50-out , Xform: parsing... 
Cannot start element "BODY" : not permitted by the document structure, 
line 11, col 35 

in: *<noframes><body bgcolor="# FFFFFF"> * 

at: > * 

[Jun 17 12:39:11 CEST 2000] Service-50-out , Xform: transforming... 
[Jun 17 12:39:11 CEST 2000] Service-50-out , Xform: done. 
[Jun 17 12:39:11 CEST 2000] Service-50 ended 

[Jun 17 12:39:11 CEST 2000] Captured response 

HTTP/1.0 302 Redirected by transform 
location: http: //xgate. jaxo.com/gjm/airport. rd 
content-type: text /vnd . wap . wml ; charset=ISO-8859- 1 
date: Sat, 17 Jun 2000 09:42:57 GMT 
last-modified: Wed, 17 May 2000 16:10:48 GMT 
accept-ranges: bytes 

link: <http: //www.aeroport . f r /Uccega/NTE/Html /FR/HP/home . htm? PageServ ices > ; 
rel="PageServices" 

server: Net scape-Enterprise/ 3 .5.1 
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(Jun 17 12:39:11 CEST 2000] Service-51 started 

[Jun 17 12:39:12 CEST 2000] Service-51, Proxy: plain copy 

(Jun 17 12:39:12 CEST 2000] Service-51-in : GET 

http: //www.aeroport . f r/Uccega/NTE/Html/FR/HP/2 . htm HTTP/1 . 0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset : ISO-8859-1, UTF-8 

host: www.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 17 12:39:12 CEST 2000] Service-51-out : HTTP/1.0 200 OK 

content-type: text/html 

date: Sat, 17 Jun 2000 09:43:03 GMT 

last-modified: Wed, 17 May 2000 16:10:48 GMT 

accept-ranges : bytes 

link: <http: //www . aeroport . f r/Uccega/NTE/Html/FR/HP/2 . htm?PageSe rvices> ; 

rel = " PageServices" 

content-length: 2603 

server: Netscape-Enterprise/3 .5.1 

[Jun 17 12:39:13 CEST 2000] Service-51-out , Xform: parsing... 
Cannot start element "BODY" : a required element is missing in TITLE 
line 10, col 23 

in: 1 <BODY bgColor=ff f f f f f f > • 

at: > * 

[Jun 17 12:39:13 CEST 2000] Service-51 -out , Xform: transforming... 
[Jun 17 12:39:13 CEST 2000] Service-5 1-out , Xform: done. 
[Jun 17 12:39:13 CEST 2000] Service-51 ended 

[Jun 17 12:39:13 CEST 2000] Captured response 

HTTP/1.0 200 OK 

content-type: text/vnd . wap. wml; charset=ISO-8859-l 
date: Sat, 17 Jun 2000 09:43:03 GMT 
last-modified: Wed, 17 May 2000 16:10:48 GMT 
accept-ranges: bytes 

link: <http: //www.aeroport . f r/Uccega/NTE/Html/FR/HP/2 . htm?PageServices>; 
rel="PageServices" 

server: Netscape-Enterprise/3 .5.1 
<?xml version="l . 0"?> 

<!DOCTYPE wml PUBLIC " -/ /WAPFORUM//DTD WML 1.1 //EN" 
"http: / /www. wapf orum. org/DTD/wml__l . 1 . xml"> 

<wmlxtemplatexdo type="prev*' label = "Back"xprev/x/dox/ tempi at e> 

<card t itle="Montpellier"xp> 

<a href="/$ (sid) /airport . 21" >Departs</a> 

<a href="/$ (sid) /airport . 22">Arrivees</ax/px/cardx/wml> 




25/28 peuuie avant reeducation 



FIGURE 25 



fJun 17 12:39:18 CEST 2000] Service-52 started 

IJun 17 12-39:18 CEST 2000] Service-52, Proxy: plain copy 

accept: text/html 
proxy-connect ion : Keep-Al ive 
accept-charset: ISO-8859-1, UTF-8 
host: www.aeroport. f r 
user-agent: JaxoXform (1-25) 

[jun 17 12:39:26 CEST 2000] Service-52-out = HTTP/1-0 200 NeXT 

content-type: text /html 

date: Sat, 17 Jun 2000 09:43:17 GMT 

content-length : 563 

server: Netscape-Enterprise/3 . 5 . 1 

TJun 17 12*39:27 CEST 2000] Service-52-out , Xform: parsing... 
jun 17 12:39:31 CEST 2000] Service-52-out , Xform: transforming... 
[Jun 17 12:39:31 CEST 2000] Service-52-out , Xform: done. 
(Jun 17 12:39:31 CEST 2000] Service-52 ended 
[Jun 17 12:39:31 CEST 2000] Captured response — 
HTTP/1.0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd . wap . wml ; charset=ISO-8859 1 
date: Sat, 17 Jun 2000 09:43:17 GMT 

server: Netscape-Enterprise/3 . 5 . 1 ; m 
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[Jun 17 12:39:32 CEST 2000] Service-53 started 

[Jun 17 12:39:32 CEST 2000] Service-53, Proxy: plain copy 

r Tun 17 12-39*32 CEST 2000] Service-53-in : GET 

6431/Apt_FlightsResponse. wo/364 1300000736431 /l/l/Mermoz HTTP/ 1.0 

accept: text/html 
proxy-connection: Keep-Alive 
accept-charset: ISO-8859-1, UTF-8 
host: www.aeroport.fr 
user-agent: JaxoXform (1.25) 

[Jun 17 12:39:33 CEST 2000] Service-53-out : HTTP/1.0 200 NeXT 

content-type: text/html 

date: Sat f 17 Jun 2000 09:43:23 GMT 

content-length: 4 71 

server: Netscape -Enterprise/ 3 . 5. 1 

[Jun 17 12:39:33 CEST 2000] Service-53-out , Xform: parsing... 
[Jun 17 12:39:34 CEST 2000] Service- 53-out , Xform: transforming... 
[Jun 17 12:39:34 CEST 2000] Service-53-out , Xform: done. 
[Jun 17 12:39:34 CEST 2000] Service-53 ended 

[Jun 17 12:39:34 CEST 2000] Captured response 

HTTP/1.0 302 Redirected by transform 
location: http: //xgate . jaxo . com/g jm/ai rport . rd 
content-type: text /vnd . wap . wml ; charset=ISO-8859- 1 
date: Sat, 17 Jun 2000 09:43:23 GMT 

server: Net scape-Enterprise/ 3 . 5 . 1 



CABINET REGIM8EAU 

DUPLICATA 

csrttfia conforms a Foriginal 



27/28 



FeuUife want* 



FIGURE 27 



(lun 17 12-39:34 CEST 2000] Service-54 started 

\jZ 17 12-39:34 CEST 20001 Service-54, Proxy: plain copy 

643?/A P t_DayFlights. wo/7507100000936431/0. 1/1/Mermoz HTTP/1.0 

accept: text/html 
proxy-connection: Keep-Alive 
accept-charset: ISO-8859-1, UTF-8 
host: www.aeroport.fr 
user-agent: JaxoXform (1.25) 

[Jun 17 12:39:41 CEST 2000] Service-54-out: HTTP/1.0 200 NeXT 
I content-type : text/html 

date: Sat, 17 Jun 2000 09:43:31 GMT 

content-length: 3054 3 
I server: Netscape-Enterpr ise/3 .5.1 

If Tun 17 12-39-41 CEST 20001 Service- 54 -out , Xform: parsing... 

Jun 17 12-39:43 CEST 2000] Service-54 -out , Xform: t rans f ormxng . . - 

Jun 17 12 : .39:47 CEST 2000] Service-54 -out , Xform: done. 
[Jun 17 12:39:47 CEST 2000] Service-54 ended 
j [Jun 17 12:39:47 CEST 2000] Captured response 

HTTP/1.0 200 NeXT QRS9-1 
content-type: text /vnd . wap . wml ; charset-ISO-8859 1 
date: Sat, 17 Jun 2000 09:43:31 GMT 
cache-control: max-age=0 
cache-control: must-revalidate 
j server : Netscape-Enterpr ise/3 . 5 . 1 

<' ? xml version="1.0"?> , 
ODOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 

JSS USr-S^lBB, AF 7725<br/>*J183; ^J^^Zil^" 
Lyon<br/>.ll83; AF7862<br/>JJ183; eco J* t ^ nt 

SN4882<br/>ll:15 Nlce< ^ f/'" ' J"" 2 "reqistrement Hl-H2<br/>12 : 00 Londres 
Marseille<br/>&*183; AF5763<br/>&#183, En regis tremens . B ruxelles<br />«,# 183 ; 

GatwicK< b r/> S «183; AFS852<br/>«U83; =»«g«tr«en J^^f , ^ 3 ; r V M103<br />14 : 00 
SN3610<br/>S#183; Enregistrement «1-G2<br/>12 15 Bruxel 

Palma<br/>S#183; 2R478<br/>14 : 15 Paris - C ^ b ^^*^ 85 5<br/>16 05 Malaga<br/>s»183; 

^^^^ 

Nice<br/>&tfl83; FU17 6<br/></p></card></wml> _ 
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$Id: xfdocJD. l.dtd, v 1.12 1999/05/17 15:56:26 pgr Exp $ 
(C) Copyright JAXO-Europe SA 1999-2000 

This work contains confidential trade secrets of JAXO-Europe SA. 

Use, examination, copying, transfer and disclosure to others 

are prohibited, except with the express written agreement of JAXO. 

xf:doc documents conversion scripts 

Typical usage: 

<?xml version=' 1 . 0 • ?> 

<!DOCTYPE xf:doc PUBLIC "-/ /JAXO/ /DTD XFDOC 0.1 Draft//EN" 

"http: //www. jaxo.com/DTD/xfdoc_0 . 1 .dtd"> 

<xf : doc xmlns : xsl= M http : //www . jaxo . com/DTD/xf doc_0 . 1 . dtd" version^ • 1 - 0 1 > 

<xf: template match="X"> 
<! — ECMAScript for X — > 
</xf: template match="X"> 

<xf: template match="Y"> 
<! — ECMAScript for Y --> 
</xf: template match-" Y"> 

<xf : scripts> 

<!-- local scripts and variables, called from any template --> 
</xf : scripts> 

</xf :doc> 

Author: 

Pierre G. Richard <pgr6jaxo.com> 



< ! ENTITY % XF. Version "-/ /JAXO/ /DTD XFDOC 0.1 Draft//EN"> 

< ! ELEMENT xf:doc (xf:init?, (xf:template | xf : scripts ))* > 
< ! ATTLIST xf:doc 

in-content-type CDATA fllMPLIED 

out-content-type CDATA 8 REQUIRED 

xmlns :xsl CDATA # IMPLIED 

version CDATA 8 IMPLIED 



— > 



> 



<! ELEMENT xf: template 
<! ATTLIST xf: template 
match 



CDATA> 



CDATA fj IMPLIED 
CDATA tf IMPLIED 



name 



> 



<! ELEMENT xf: scripts 
<! ELEMENT xf : init 



CDATA> 
CDATA> 
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FIG. 2 



"J 

* ' 




r — — •> 

■ 






WML 

^ J 




Content 
(XML) 




HTML 

k J 




WML 
Browser 



HTML 
Browser 



3 128 

FIG.3 



4/28 



FIG. 4 



Application e-commerce 
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Conversion HTML WML 



www. aeroport.tr 



Gradin 4: 
Fourniture 
Donnees 



Gradin 3: 
Conversion 
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Transport 
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Transformation : flux 




XF 
Script 
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F1G.7 

AGREGATION ET TRANSFORMATION 
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<xf:template match=DPD> 
(procedure P) 
</xf:template> 
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<xf:template match= n HTML"> 
XF.trace(); 

XF.applyTemplatesCoriginO.descendanttall^FRAMESET | BODY))"); 
</xf:template> 
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<xf:template match="FRAMESET"> 
XF,setVar("framedM); |Q1 



var list = this.getChildNodes(); 
f or (var i=0; ;++i) { f 



var child = list.item(i); 



102 



if (child == null) break; 
if (child.getNodeNameO == "FRAME") { 
var name = child.getAttributefname"); 

if( 

((name == null) && (child.getNextSibling() == null)) | | 
(name == "HOME") | | (name == "MainMenu") | | 
(name == "Content") | | (name == "Result") 

){ 

XF.rediredTo(child.getAttribute("src"))); 
break; 

} 

} 

</xf:template> 
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<xf:template name="body" match="BODY" ^ 
( if (null == XF-getVarCframed")) { 
( XF.result().write(prolog); 111 
var uri = XF.getURLQ; 

if (url.indexOffDayFlight") > 0) { ^ 11 resull ~ 114 

XF.applyTemplat es("orjgin().descendant(all,TBODY)"); 
}else { \ f II HomePage ( Dep/Arr) J 

XF.applyTemplates("origin().descendant(all,IMG)°); jH^~ 




( XF.result().write(epilog);") 



} 

</xf:temp1ate> 
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<?xml version^" 1.0\ H ?> 






<!D0CT7PE wml PUBLIC "-//WAPFORUM//DTD WML 1 . 1 //EN" 
"http://www.wapforum.org/DTD/wml_1 .1 ,xml\"> 

<wml> 


v prologue 


I 


<card> 






<P> 






<a href= n http://ddddd">Departs</a> 
<a href="http://aaaaa">Arrivees</a> 






</p> 
</card> 


i 
i 

, y epilogue 




</wml> 
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<xf:template name="menultem" match="IMG*3 ,, > 
var text = this.getAttribute("src"); 
if (text.indexOf("DEPARr) > 0) { 

addAnchor(this, "Departs", "airport.21"); 
}else if (text.indexOf("ARRIVE") > 0) { 
addAnchor(this, "Arrivees", "airport.22"); 

} 

</xf:template> 
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<xf :scripts> 
function addAnchor(node, text, localRef) { 
while (null != (node = node.getParentNode())) { 
if (node.getNodeName() == 'A') { 
XF.result().writeAnchor(text, node.getAttributefhref), localRef) 
break; 

} 

} 

} 

</xf:scripts> 
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Texte Departs 

Ref hypertexte http://www.montp€llier.aeroport.fr/cgi-bin/WebObjects.dll/Uccega/M 
Ref locale airport. 21 



16/28 



FIG.16 



Affichage du tableau des horaires 



•^F&^i- 



TR 



17:50 




BA6807 




4 



25/03 



Londres Gatwick 



British Airways Enregistrement 



J1-J2 
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<xf:template match="TBODY n > 
var list = this.getChildNodes(); 
for (var i=0; ;++i) { 
child = list.item(i); / 

if (child == null) break; ) 

if (child.getAttribute("bgcolor H ) == "FFFFFF") { // irrelevant) 



i +=- 3; f 

jj else{ 173 

var data = new FlightDataQ; ) — ' 
XF.applyTemplates( L 



"origin ( ) .child (" + i + n ).descendant(all ) #text) , \ \ 
" d J data / — 7 

XF.result().write(data.timeFrom + "<br/>" + data-others) 

} } v 174 

</xf:template> 
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La procedure template pour chaque portion de texte s'ecrit simplement 



<xf:template name= H flight M match- 'textO'^ 
var text = this.getNodeValue().reduce(); 
if (text.length > 0) { 
var i = arg0.item++; 
if (j == 1 ) { argO.timeFrom = text + 



else if 
else if 
else if 
else if 
else if 



// arrival time 
// from 



} 

</xf:template> 



= 2) argO.timeFrom += text; 
== 3) argO.others = "." + text + °<br/> n ; // airline 
== 4) argO.others += "." + text + "<br/>"; // buildg 
== 5) argO.others += "." + text + "<br/>"; // remarks 
== 6) argO.others += "." + text + "<br/>"; // departure time 
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[Jun 17 12:38:55 CEST 2000] Service-47 started 
[Jun 17 12:38:55 CEST 2000] Service-47, Proxy: plain copy 
[Jun 17 12:38:55 CEST 2000] Service-47-in: GET http://www.Nantes.aeroport.fr HTTP/1.0 
accept: text/html 
proxy-connection: Keep-Alive 
accept-charset: ISO-8859-1 , UTF-8 
host: www.Nantes.aeroport.fr 
user-agent: JaxoXform (1.25) 



[Jun 1 7 1 2:38:56 CEST 2000] Service-47-out: HTTP/1 .0 200 OK 

content-type: text/html 

date: Sat, 1 7 Jun 2000 09:42:47 GMT 

last-modified: Fri, 12 May 2000 14:53:47 GMT 

accept-ranges: bytes 

link: <http://www.aeroport.fr/7PageServices>; rel=TageServices B 

content-length: 5932 

server: Netscape-Enterprise/3.5.1 

[Jun 17 12:38:56 CEST 2000] Service-47-out, Xform: parsing... 
Cannot start element "META": a required element is missing in BODY 
line 3, col 76 

in: '"Content-Type" CONTENT="text/html; charset=iso-8859-1 u >' 

at; > 

Cannot start element "META": a required element is missing in BODY 
line 4, col 451 

in: 're, terminal, piste, runway, fret aerien, air freight*^' 
at: > 

Cannot start element "META": a required element is missing in BODY 
line 5, col 403 

in: 'mercial services, tourism in the Aquitaine region ... u > </head>* 
at: >- 

Warning: invalid end tag: "HEAD" 
line 5, col 413 

in: 'rvices, tourism in the Aquitaine region ..."> </head>' 
at : > 

Warning: invalid end tag: "NOFRAMES" 

line 60, col 1 2 

in: ^/noframes^ 

at: > * 

[Jun 17 12:38:57 CEST 2000] Service-47-out, Xform: transforming... 
[Jun 17 12:38:57 CEST 2000] Service-47-out, Xform: done. 
[Jun 17 12:38:57 CEST 2000] Service-47 ended 

[Jun 17 12:38:57 CEST 2000] Captured response 

HTTP/1 .0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd.wap.wml; charset=IS0-8859-1 
date: Sat, 17 Jun 2000 09:42:47 GMT 
last-modified: Fri, 12 May 2000 14:53:47 GMT 
accept-ranges: bytes 

link: <http://www.aeroport.fr/7PageServices>; rel="PageServices" 
server: Netscape-Enterprise/3.5.1 
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Jun 17 12:38:58 CEST 2000] Service-48 started 

Jun 1 7 1 2:38:58 CEST 2000] Service-48, Proxy: plain copy 

Jun 17 12:38:58 CEST 2000] Service-48-in: GET http://www.nantes.aeroport.fr/scripts/WebObjects/Uccega/NTE 

HTTP/1 .0 
accept: text/html 
proxy-connection: Keep-Alive 
accept-charset: ISO-8859-1, UTF-8 
host: www.nantes.aeroport.fr 
user-agent: JaxoXform (1.25) 

[Jun 17 12:38:59 CEST 2000] Service-48-out: HTTP/1.0 200 NeXT 

content-type: text/html 

date: Sat, 1 7 Jun 2000 09:42:49 GMT 

content-length: 321 

server. Netscape-Enterprise/3.5.1 

[Jun 1 7 1 2:38:59 CEST 2000] Service-48-out, Xform: parsing... 
[Jun 17 12:38:59 CEST 2000] Service-48-out, Xform: transforming... 
[Jun 17 12:38:59 CEST 2000] Service-48-out, Xform: done. 
[Jun 1 7 1 2:38:59 CEST 2000] Service-48 ended 

[Jun 1 7 1 2:38:59 CEST 2000] Captured response 

HTTP/1 .0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd.wap.wml; charset=ISO-8859-1 
date: Sat, 17 Jun 2000 09:42:49 GMT 
server: Netscape-Enterprise/3.5.1 
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[Jun 1 7 1 2:38:59 CEST 2000] Service-49 started 

[Jun 17 12:39:00 CEST 2000] Service-49, Proxy: plain copy 

[Jun 17 12:39:00 CEST 2000] Service-49-in: GET 

http://www.nantes.aeroport.fr/scriptsW^^ 1 0 

000053643 1 /Main.wo/7 1 92 1 0000043643 1/1/1 /Mermoz HTTP/1 .0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset: ISO-8859-1 , UTF-8 

host: www.nantes.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 1 7 1 2:39:05 CEST 2000] Service-49-out: HTTP/1 .0 200 NeXT 

content-type: text/html 

date: Sat, 1 7 Jun 2000 09:42:52 GMT 

content-length: 490 

server: Netscape-Enterprise/3.5.1 

[Jun 17 12:39:05 CEST 2000] Service-49-out, Xform: parsing... 
[Jun 1 7 1 2:39:05 CEST 2000] Service-49-out, Xform: transforming... 
[Jun 1 7 1 2:39:05 CEST 2000] Service-49-out, Xform: done. 
[Jun 1 7 1 2:39:05 CEST 2000] Service-49 ended 

[Jun 1 7 1 2:39:05 CEST 2000] Captured response 

HTTP/1 .0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd.wap.wml; charset=IS0-8859-1 
date: Sat, 1 7 Jun 2000 09:42:52 GMT 
server: Netscape-Enterprise/3.5. 1 
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[Jun 17 12:39:05 CEST 2000] Service-50 started ~ " ~ 

[Jun 17 12:39:06 CEST 2000) Service-50, Proxy: plain copy 

u^dh n 2:39: ° 6 CEST 20001 Service - 5 °- in: GET h ttp://www.aerorx)rt.fr/Uccega/NTE/Html/FfVHP/home.htrn 
HI I r / 1 .0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset: ISO-8859-1, UTF-8 

host: www.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 1 7 1 2:39: 1 0 CEST 2000) Service- 50-out: HTTP/1 .0 200 OK 

content-type: text/html 

date: Sat, 17 Jun 2000 09:42:57 GMT 

last-modified: Wed, 1 7 May 2000 1 6:1 0:48 GMT 

accept-ranges: bytes 

ink: <http://www.aeroport.fr/Uccega/NTE/Html/FR/HP/home.htm7PageServices>; rel=TaqeServices" 
content-length: 507 ' 

server: Netscape-Enterprise/3 .5.1 

Jun 17 12:39:10 CEST 2000] Service-50-out, Xform: parsing... 
Cannot start element "BODY": not permitted by the document structure 
line 11, col 35 

in: ' <noframes> <body bgcolor= tt #FFFFFF tt > ' 
at: > * 

Jun 17 12:39:11 CEST 2000] Service-50-out, Xform: transforming. 
Jun 1 7 1 2:39: 1 1 CEST 2000] Service-50-out, Xform: done. 
Jun 17 12:39:11 CEST 2000] Service-50 ended 

Jun 1 7 12:39:1 1 CEST 2000] Captured response 

HTTP/1 .0 302 Redirected by transform 
ocation: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd.wap.wml; charset= ISO-8859-1 
ate: Sat, 1 7 Jun 2000 09:42:57 GMT 
ast-modified: Wed, 17 May 2000 16:10:48 GMT 
accept-ranges: bytes 
ink: <http://^ 
server: Netscape-Enterprise/3. 5.1 
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(Jun 17 12:39:1 1 CEST 2000] Service-51 started 

[Jun 17 12:39:12 CEST 2000] Service-51 , Proxy: plain copy 

[Jun 17 12:39:12 CEST 2000] Service-51 -in: GET http://www.aeroport.fr/Uccega/NTE/Html/FR/HP/2.htm 

HTTP/1.0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset: ISO-8859-1 , UTF-8 

host: www.aeroport.fr 

user-agent: JaxoXform (1.25) 

[Jun 1 7 1 2:39:1 2 CEST 2000] Service-51 -out: HTTP/1 .0 200 OK 

content-type: text/html 

date: Sat, 17 Jun 2000 09:43:03 GMT 

last-modified: Wed, 1 7 May 2000 1 6:1 0:48 GMT 

accept-ranges: bytes 

link: <http://www.aeroport.fr/Uccega/NTE/Html/FR/HP/2.htm?PageServices>; rel="PageServices" 

content-length: 2603 

server: Netscape-Enterprise/3.5.1 

[Jun 17 12:39:13 CEST 2000] Service-51 -out, Xform: parsing... 
Cannot start element "BODY": a required element is missing in TITLE 
line 10, col 23 

in: "<B0DY bgColor=#ffffff>' 

at; > • 

[Jun 17 12:39:1 3 CEST 2000] Service-51 -out, Xform: transforming... 
[Jun 1 7 1 2:39:1 3 CEST 2000] Service-51 -out, Xform: done. 
[Jun 17 12:39:13 CEST 2000] Service-51 ended 

[Jun 1 7 1 2:39:1 3 CEST 2000] Captured response 

HTTP/1 .0 200 OK 

content-type: text/vnd.wap.wml; charset= ISO-8859-1 
date: Sat, 1 7 Jun 2000 09:43:03 GMT 
last-modified: Wed, 1 7 May 2000 16:10:48 GMT 
accept-ranges: bytes 

link: <http://www.aeroport.fr/Uccega/NTE/Html/FR/HP/2.htm?PageServices> ; rel="PageServices" 
server: Netscape-Enterprise/3.5.1 
<?xml version="1.0"?> 

<!D0CTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1 . 1//EN" "http://www.wapforum.org/DTD/wml_1 .1 .xml"> 

<wml><template><do type="prev" label="Back"><prev/x/do></template> 

<card title="Montpellier"><p> 

<a href=7$(sid)/airport.2r>Departs</a> 

<a href=7$(sid)/airport.22">Arrivees</a></p></card></wml> 
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' Jun 17 12:39:18 CEST 2000] Service-52 started 
Jun 1 7 1 2:39:1 8 CEST 2000] Service-52, Proxy: plain copy 
Jun 17 12:39:18 CEST 2000] Service-52-in: GET 

ttp://\^.aeroport.fr/scripts/WebObjeds/Uccega/NTE?action=goDayDepartures 

accept: text/html 
proxy-connection: Keep-Alive 
accept-charset: ISO-8859-1 . UTF-8 
host: www.aeroport.fr 
user-agent: JaxoXform (1.25) 

[Jun 1 7 1 2:39:26 CEST 2000] Service-52-out: HTTP/1 .0 200 NeXT 

content-type: text/html 

date: Sat, 1 7 Jun 2000 09:43: 1 7 GMT 

content-length: 563 

server: Netscape-Enterprise/3.5.1 

[Jun 17 12:39:27 CEST 2000] Service-52-out, Xform: parsing... 
[Jun 17 12:39:31 CEST 2000] Service-52-out, Xform: transforming... 
[Jun 17 12:39:31 CEST 2000] Service-52-out, Xform: done. 
[Jun 17 12:39:31 CEST 2000] Service-52 ended 

[Jun 17 12:39:31 CEST 2000] Captured response 

HTTP/1 .0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd.wap.wml; charset=ISO-8859-1 
date: Sat. 17 Jun 2000 09:43:17 GMT 
server: Netscape-Enterprise/3.5.1 
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[Jun 17 12:39:32 CEST 2000] Service-53 started 

[Jun 17 12:39:32 CEST 2000] Service-53, Proxy: plain copy 

[Jun 17 12:39:32 CEST 2000] Service-53-in: GET 

http://v^.aeroport.fr/scripts/WebObjects/Uccega/NTE.woa/679800000057832000002 1 00 1 0000083643 1 / 

Apt_FlightsResponse.wo/3641 30000073643 1/1/1 /Mermoz HTTP/1 .0 

accept: text/html 

proxy-connection: Keep-Alive 

accept-charset: IS0-8859-1 , UTF-8 

host: www.aeroport.fr 

user-agent: JaxoXform (1 .25) 

[Jun 17 12:39:33 CEST 2000] Service-53-out: HTTP/1 .0 200 NeXT 

content-type: text/html 

date: Sat, 1 7 Jun 2000 09:43:23 GMT 

content-length: 471 

server: Netscape-Enterprise/3.5.1 

[Jun 1 7 1 2:39:33 CEST 2000] Service-53-out, Xform: parsing... 
[Jun 17 12:39:34 CEST 2000] Service-53-out, Xform: transforming... 
[Jun 17 12:39:34 CEST 2000] Service-53-out, Xform: done. 
[Jun 17 12:39:34 CEST 2000] Service-53 ended 

[Jun 17 12:39:34 CEST 2000] Captured response 

HTTP/ 1.0 302 Redirected by transform 
location: http://xgate.jaxo.com/gjm/airport.rd 
content-type: text/vnd.wap.wml; charset=IS0-8859-1 
date: Sat, 1 7 Jun 2000 09:43:23 GMT 
server: Netscape-Enterprise/3.5.1 
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[Jun 17 12:39:34 CEST 2000] Service-54 started 
I [Jun 17 12:39:34 CEST 2000] Service-54, Proxy: plain copy 
f Inn 17 12-39-34 CEST 20001 Service-54-'m: GET 

hts.wo/7507100000936431/0.1 /1/Mermoz HTTP/1 .0 

accept: text/html 
proxy-connection: Keep-Wive 
acccpt-charset: ISO-8859-1 , UTF-8 
host: www.aeroport.fr 
user-agent: JaxoXform (1.25) 

[Jun 17 12:39:41 CEST 2000] Service-54-out: HTTP/1.0 200 NeXT 

content-type: text/html 

date: Sat. 17 Jun 2000 09:43:31 GMT 

content-length: 30543 

server: Netscape-Enterprise/3.5.1 

[Jun 17 12:39:41 CEST 2000] Service- 54-out, Xform: parsing... 
[Jun 17 12:39:43 CEST 2000] Service- 54-out, Xform: transforming... 
[Jun 17 12:39:47 CEST 2000] Service- 54-out, Xform: done. 
[Jun 17 12:39:47 CEST 2000] Service-54 ended 

[Jun 17 12:39:47 CEST 2000] Captured response 

HTTP/1 .0 200 NeXT 

content-type: text/vnd.wap.wml; charset=IS0-8859-1 
date: Sat. 17 Jun 2000 09:43:31 GMT 
cache-control: max-age=0 
cache-control: must-revalidate 
server: Netscape-Enterprise/3 .5.1 

<?xml version="1.0"?> .„ 
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1 .1 //EN" "http://www.wapforum.org/DTD/wml_1 .1 .xml > 
<wml><template><do type="prev" | a bel="Back"><prev/></do></template> 

^0 ptrir-Cdg<rr/> P · AF7725<br/>· Enregistrement D1-E2<br/>1 1:1 ^ L yon<br/>6,#183; 
AF7862<br/>&#183- Decolle 1 1:23<br/>1 1:15 Nice<br/>· SN4882<br/>1 1:15 N.ce<br/>&#183 

H1-H2<br/>12:00 Londres Gatwick<br/>· AF5852<br/>· Enregistrement n-l2<br/> 12: 15 
Bm X dles<br/>·SN3610<br/>·EnregistrementG1-G2<br/>12^ 

VM103<br/>14:00 Palma<br/>· 2R478<br/>14:15 Par.s-Cdg<br/>· *™]<™> 1 ^5.45 Pans- 
Cdg<br/>· AF7729<br/> 1 5:55 Brest<br/>· AF5853<br/> 16:05 M a 'a9a<br/>&# 83; 
JK4544<br/>16:15Athenes<br/>&#183^^ 
Marseille<br/>· FU765<br/> 18:35 Marseille<br/>· AF5765<br/> 18:40 Londres Gatw.ck<br/>&#183 
AF5854<br/> 18:50 Londres Gatwick<br/>· BA6807<br/> 1 9:20 Nice<br/>· 
FU 1 76<br/></p></cardx/wml> 
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<!-- 



$ld: xfdoc_0.1.dtd,v 1.12 1999/05/17 15:56:26 pgr Exp $ 
(C) Copyright iAXO-Europe SA 1999-2000 

FIG 28 ™ s work contains confidential trade secrets of JAXO-Europe SA. 

Use, examination, copying, transfer and disclosure to others 
are prohibited, except with the express written agreement of JAXO. 



xf:doc documents conversion scripts 



Typical usage: 

<?xml version- 1.0?> 

<!D0CTYPE xf:doc PUBLIC "-//JAX0//DTD XFDOC 0.1 Draft//EN" 
"http://www.jaxo.com/DTD/xfdoc_0. 1 .dtd°> 

<xf:doc xmlns:xsl= n http://www.jaxo.com/DTD/xfdoc_0.1 .dtd fl version=M .0'> 

<xf:template match= n X"> 
<!-- ECMAScript for X »> 
</xf:template match="X M > 

<xf:template match="Y"> 
<!-- ECMAScript for Y-> 
</xf:template match-T'> 

<xf:scripts> 

<!- local scripts and variables, called from any template --> 
</xf:scripts> 

</xf:doc> 

Author: 

Pierre G. Richard <pgr@jaxo.com> 

-> 

<! ENTITY % XF.Version "-//JAX0//DTD XFDOC 0.1 Draft//EN H > 

<! ELEMENT xf:doc (xf:init?, (xftemplate | xf:scripts))*> 
<!ATTLISTxf:doc 

in-content-type CDATA #IMPLIED 

out-content-type CDATA #REQUIRED 

xmlns:xsl CDATA #IMPLIED 

version CDATA #IMPLIED 



<!ELEMENT xfttemplate CDATA> 

<!ATTLIST xf:template 

match CDATA #IMPLIED 

name CDATA #IMPLI ED 

> 

<!ELEMENTxf.scripts CDATA> 
<!ELEMENT xftinit CDATA> 
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